The 2.0.0 release is now feature complete. Just need a few weeks and additional testing to make sure everything is rock solid before declaring it stable.
This release comes with integrations to this service, improved security through better encryption and hashing algorithms. Also now includes continuous backup support on top of the regularly scheduled backups that were supported before was the last major feature addition.
Get it now from the downloads page.
If key recovery is enabled the private key of your backup source is encrypted using your account email as the password using the same Argon2 algorithm as is used for other passwords. This operation happens in the client so the private key is never directly transferred to the service before hashing.
The resulting data is then encrypted using a KMS key before stored in the service. You also have an option of what region you wish this data to be stored in to further give you full control over the data sovereignty of this very critical piece of information.
To further protect your data, the email of your account is not stored anywhere in the system except for the billing system and only if you have email billing enabled. In all other cases only a hash of an email is stored or transmitted to the service (With a few notable denoted below). In the unlikely event of a system compromise both the backup storage service and the external billing system (Stripe) would need to be compromised for any risk of customer data being accessed. The only other times when the email is transmitted in clear text in the service (but not stored) to the service is when you sign up, reset your password or change your account email. You can change your email billing setting under you account settings page.
You always have the option to disable the private key recovery feature if this risk is unacceptable.
Private key recovery can only be started during initial application setup when adopting an existing source. At this point choose the "Private Key Recovery" option on the password page of the setup wizard. You will be prompted for a new password to apply once the private key has been recovered and then redirected to the Underscore Backup service where you will be prompted for your credentials before the stored encrypted private key is returned to the application where they can be decrypted using your account email address.
As described above the email is the key with which the private key is encrypted with which causes a problem when you are changing your account email. What happens in this case is that the old email and new email is kept in the browser when verifying the email change. The encrypted source private keys are then downloaded to your browser, decrypted with the old email, re-encrypted with the new email and uploaded back up to the service. Only after all private keys have been stored encrypted with the new email will the account email actually be changed. It is important to not that at no point during this operation is either the old email, the new email or any of the private keys handled in clear text by the service.
The only exception is the initiation of the email change at which point the email is sent to the service, although this email is never stored anywhere but is only used to send the password validation email.
Asymmetric encryption or public key cryptography is a class of encryption where you have a public key that is derived from a private key. To be a good asymmetric crypto it should be very hard to derive the private key from the public key. Examples of this kind of encryption is used in a lot of places such as PGP (Encrypted messages), TLS (In transit internet connections). The first popular asymmetric algorithm is RSA which is still in wide use even though it is starting to show its age. More modern algorithms include a variety of elliptic curve cryptography algorithms.
Underscore Backup uses the X25519 elliptic curve crypto to encrypt all its data. The way this works is that the private key for this crypto is derived from the password used to encrypt the backup. Only the public key is ever stored on disk or in the backup destinations. A neat feature of public key cryptography is that you need the public key to encrypt data, but you need the private key to decrypt the data. The upside of this is that when Underscore Backup is running in the background on your computer it does not even have the private key required to read your backup, it can only write backups.
What this means is that if your computer gets compromised that means that the contents of your backups are not compromised along with your computer. Only when you enter your password into your application to do a restore will the application have the private key in memory (It is never committed to disk) and it will make sure to forget it as soon as your restore operation is complete.
The private key for encryption is derived from your password using the Argon2 algorithm. Once this is created during setup the public key and the password salt is stored in both your manifest directory and uploaded to your manifest backup destination. For every backup block (A backup block is around 8mb of backup data) that is stored in the backup destination a new X25519 private and public key pair is created. The block public key is stored in a header in the block, the block private key is combined with the backup public key using a Diffie-Hellman key exchange. The resulting 256 bit key is then used to encrypt the rest of the backup block using the symmetric AES 256 encryption scheme.
A Diffie-Hellman key exchange has the property that given two public/private key pairs if you combine the public key of one key and the private key of the other you end up with the same result as when you do it with the other public/private key pair. In the previous operation the private key for the block is discarded after the block has been written (And as noted the public key is written with the block itself). That means that after the block has been written only the backup private key can be used with the block public key to get the symmetric encryption key to read the block.
The first release for the 2.0 beta has now been released and is available for download on for download.
The main new feature though is the introduction of this companion service that will help with many aspects of running Underscore Backup such as.
With this release, the registration for accounts on this service has also been opened.
On top of the companion service changes, the following features and improvements are implementing.
The one major feature planned before 2.0 is to be completed is to add continuous backup functionality.
In some cases, especially if you wish to increase the number of parallel uploads and downloads you might wish to increase the maximum heap memory usage for the application.
You need to find a file in the distribution of the application called underscorebackup.cfg. The location of this file depends on your OS. On Windows it is located in C:\Program Files\Underscore Backup\app\underscorebackup.cfg and there is also a second file used for the GUI application called C:\Program Files\Underscore Backup\app\underscorebackup-gui.cfg. On Linux it is located in /opt/underscorebackup/lib/app/underscorebackup.cfg. On MacOS you need to open the Underscore Backup app bundle (Right click, open) and then find the file lib/app/underscorebackup.cfg.
Once you found this file (Or files on Windows) you need to edit the following line.
[JavaOptions] java-options=-Xmx256m
To increase your usage edit the -Xmx256m to reflect your new value. For instance if you want to use 1GB of memory you could edit it to -Xmx1024m.
On Windows and Linux this edit will be persisted between application upgrades as of version 2.0.0pre2 and later. However on MacOS unfortunately this change will need to be made every time the application is upgraded.
There are times when you might want to move your backup data from one location to another for instance if you have found a better or cheaper storage for your backups.
Before you make any changes I recommend you make a copy of your manifest director. On Windows the local data files are all located in the user directory AppData\Local\UnderscoreBackup.
On Unix or OSX if you run as a non-root user the default location of all files will be ~/.underscoreBackup.
If running as root the configuration files will be located in /etc/underscorebackup, the data files will be in
/var/cache/underscorebackup.
After this follow the following steps to move a destination.
Unfortunately there is no way to move an existing backup with history into the just released Underscore Backup service because you can not copy files into the service manually in an easy way. You can however just start making a new backup to the Underscore Backup service location. Once the initial backup is completed you can remove your old backups (Assuming you are ok with loosing old versions).
If you want to move to using the Underscore Backup service for future backup data and to keep the manifest in this location while still keeping the history of your backups you can do this following these steps.
...
"destinations": {
"d0": {
"type": "FILE",
"encryption": "AES256",
"errorCorrection": "RS",
"endpointUri": "/var/backups"
},
"d1": {
"type": "UB",
"encryption": "AES256",
"errorCorrection": "NONE",
"endpointUri": "us-west"
}
},
"manifest": {
"destination": "d1",
...
underscorebackup optimize-log
