A howto restore from remote backup (disaster recovery)

[goebbe]

Following a discussion about restoring data from a backup, I decided to test and document the restore from a remote backup server.
Scenario: Your old computer has been stolen or destroyed - so you have to use a new computer to restore your (online) backup. This means that the following is all about restoring in a worst case scenario.

In other cases, restore is much easier. If, for example, you just want to restore a file from yesterday's backup on your computer, it is sufficient to open Vorta, go to Archives, mount the archive from yesterday, browse yesterday's backup in a file manager and restore (copy and paste) the file. In this case, no additional information would be required, and you could just use your local Vorta setup.

Goal of this discussion: Document the prerequisites and necessary steps for a restore (disaster recovery).

I hope the following may be helpful in order to complement the documentation or start a discussion about what should be added to the documentation. (if anything)

The following has been tested using Vorta 0.10.3 on Linux. Please feel free to point out any mistakes.

[goebbe]

This following describes the restore of a remote backup to a new restore-computer.
The described steps would e.g. be necessary if your old computer is lost/ stolen/ destroyed, i.e. disaster recovery. :-)

DEFINITIONS:
your-old-computer - the lost/stolen/destroyed computer. You used Vorta for backups on this computer.
remote-backup-server - the server that has been used to back up files from your-old-computer. e.g. your-backupserver.org
restore-computer - another/ new computer that you use to restore your backup. The aim is to restore the backup to this computer.

REQUIRED INFORMATION:
The following bits of information are required in order to restore a remote backup from the restore-computer:
a) URL or IP address of the remote-backup-server
b) your username on the remote-backup-server
c) name of the repositories that contains the backup archives
d) path of the repositories on the remote-backup-server
e) passphrase of the encrypted repository
Additional requirement:
f) keyfile for your repository (if you use a repokey, the keyfile is not required since it is already available on your remote-backup-server)
g) access info for the remote-backup-server (URL, username, password, TFA second factor, ... in short: everything necessary to access your account at your-backupserver.org

Using Vorta, the information a)-e) can be exported on a per-profile basis as follows:

1. In Vorta, on the left side, under "Current Profile": Select a profile
2. Click on the icon at the bottom, right: Export current profile
3. A .json file with "your_profile_name.json" which contains your setting will be saved to your home directory

Recommendation for export: Export the settings of ALL profiles in .json files (as described). Important: When exporting, you can choose if the passphrase for the repository should be be included in the .json file - if you do not include the passphrase, you have to keep/ save the passphrases at another place.

Recommendation - to ensure that you have all information that is necessary for disaster recovery:

• Save your exported "your_profile_name.json" files in a password manager, then completely delete the .json files from your disc.
  (You should not keep the .json files unprotected on your computer if they contain the passphrase!)
• Save the passphrase of your backup-repository and the information required to access your account at your-backupserver.org, see g) in a password manager.
• Save your keyfile in a password manager. Use borg key export to save a backup of your repokey ,see f).
• Keep a copy of your password managers encrypted database at a save place outside your computer or even outside the building. (i.e. a offside backup of your encrypted password vault)

RESTORE:
Prerequisites:

• A restore-computer with a working Vorta installation (and an ssh client) - OS: Linux or MacOS.
• The required information a)-e) and g) for your profiles (e.g. your_profile_name.json AND access info for your remote-backup-server).
• You may require a backup of the keyfile f) for your repository. If you use a repokey (this is the default in Vorta) the keyfile is not required for restore, since it is already stored on the backup-server.

First Set up the ssh access to the remote-backup-server:
Background: Vorta use ssh with a public/ private security key pair, which can be generated on your restore-computer.

• Generate a pair of ssh_keys on the restore-computer. Hint: Vorta can generate new ssh_key pairs.
  The public and the private key are saved to ~/.ssh on your restore-computer.
  The public ssh-key typically consists of a single line of text, saved e.g. in the text file "id_ed25519.pub"
• Put your public ssh-key to your remote-backup-server.
  Consult the docs of your provider to see howto do this!
  Typically, the public ssh-key is added to ~/.ssh/authorized_keys on the remote-backup-server.
• Once the ssh keys are in place, you should be able to connect via ssh from the restore-computer to the remote backup-server without additional passwords.
  To test this, type the following, in a terminal: ssh your_remote_username@your-backupserver.org

Then, for each "Profile"/repository you want to restore:

1. Move the "your_profile_name.json" settings-file into the home directory of the restore-computer.
2. Copy/ Rename the settings-file to ".vorta.init.json".
3. Open Vorta - Vorta will automatically import the setting of the profile - from the ".vorta.init.json" setting-file.
   Info: Automatic backups will be blocked until you "Start backup" once, manually. Even if automatic backup is pre-selected in Vorta after the settings import.
   Info: The file .vorta.init.json will be automatically deleted from your home-directory, after the import of the settings.
4. If you have used a local "keyfile" for your repository, you have to copy the keyfile to the home directory manually and check if your Vorta profile is configured correctly. Use borg key import for the setup. If you have used "repokey" (the default), the keyfile is already located on the remote-backup-server, i.e. you don't have to copy / import keyfiles, in this case.
5. In Vorta > Archives: In the main area, at the bottom, left side: Click on refresh the archives bottom.
6. In Vorta > Archives: Select an archive from the list - and restore:
   You have two main options for restore:
   • either "Mount" an archive to an empty folder - and copy the required files from this folder
   • or "Extract" an entire archive to an empty folder

CLEANING UP - after restore :

• The restore-computer has now direct access to the remote-backup-server (via ssh keys)
  If you want to disable ssh access from the restore-computer, you have to delete the corresponding public key on the remote-backup-server.
  The public key is stored on the remote-backup-server, in a (hidden) file: ~/.ssh/authorized_keys The file "authorized_keys" is just a text file, that contains one public key per line - you can delete the relevant line - or use the tools provided by your-backupserver.org
• After restore, you should not leave/ keep copies of the .json files unprotected on the restore-computer.
  Hint: The file ".vorta.init.json" is automatically imported and deleted when you open Vorta.
• If you did use a local keyfile and you don't plan to use the restore-computer to access the repository in the future, you should delete the local keyfile from the home directory. In this case, you should check ~/.config/borg/keys after restore.

edit: Add requirements about "keyfiles".
edit2: Clarify, that borg key export/ import should be used to export and backup the repokeys.

[goebbe]

Testing the restore from a remote backup server, I only found one small "issue".
As part of my restore, I used the exported .json files, placed it in my home directory and renamed it to .vorta.init.json and started Vorta for the import.
Since I set up automatic backup on my old computer - the setting for automatic backup has been imported, too.
If I understand correctly: The automatic backup could be executed on the restore-computer. This may not be desired.
Edit: Even if the settings for automatic backup are imported, automatic backups will not be executed until the first manual backup.

Possible enhancement: Perhaps, in the future, one could add a differentl naming scheme for the .json file for the case of a restore. e.g. ".vorta.restore.json" - instead of .vorta.init.json in order to

• Import settings (server, repo ...) but:
• disable automatic backup !
• remove the "Resources" of the profile - to avoid accidental manual backup?
• Check if Vorta can connect via ssh to the remote-backup-server and give feedback:
  • either: ssh is already setup, then give feedback and - refresh the archives automatically
  • or: point to the existing Vorta documentation on howto set up ssh keys
• refresh archives automatically

When the .vorta.restore.json is imported - also the settings for automatic backups are imported. This is fine - however, it could lead to wrong conclusions. Automatic backup will not be executed automatically. So there is no reason to panic, when doing a restore.

For disaster backup, you may be forced to use an entirely new computer / or the computer of a close relative/ colleague. Vorta should not execute automatic backups in this case.

Any thoughts on this? Please let me know if I should open a feature request?

[real-yfprojects]

First of all, thanks for writing this detailed piece of documentation. Maybe our existing documentation can be augmented by it. You can edit the documentation in this repo.

Regarding your feature requests, I personally wouldn't deem them worth the efford of implementing except for one thing. When restoring a profile that has automatic backups enabled and also the option to catchup missed backup, it might be the case that vorta will automatically start a backup when importing the profile. Can you confirm whether this is the case? Otherwise I don't think there is a problem since one can disable automatic backups after importing the profile.

[goebbe]

@real-yfprojects Thanks for reply.
Note that currently you can only disable automatic backup manually, if you are lucky enough i.e. you have enough time to do so.
With bad luck (or bad timing), the automatic backup could start directly after starting Vorta (i.e. the import of .vorta.init.json)
With respect to the "missed backups", you are right, this should be checked.
In the described restore scenario, you probably never want Vorta to start backups automatically - on the restore-computer.

[goebbe]

@real-yfprojects To test if Vorta tries to "run missed backups after startup", I set up a test backup with automatic backup and "run missed backups..." on my old computer, exported the settings to my restore-computer and imported the settings.
Result: I got a raised exception because of my network-manager (I guess this is unrelated) - and the following lines on the terminal:

2024-02-06 21:20:41,748 - vorta.borg.jobs_manager - DEBUG - Finish job for site: default
2024-02-06 21:20:41,749 - vorta.borg.jobs_manager - DEBUG - No more jobs for site: default
2024-02-06 21:20:41,750 - vorta.scheduler - DEBUG - Refreshing all scheduler timers
2024-02-06 21:20:41,767 - vorta.scheduler - INFO - Setting timer for profile 2
2024-02-06 21:20:41,778 - vorta.scheduler - INFO - Nothing scheduled for profile 2 because it would be the first backup for this profile.

Profile 2 should be the imported profile. If I interpret the last line correctly, "run missed backups" is not executed, here.

In addition I tested what happens at the next automatic backup time:

2024-02-06 21:35:39,805 - vorta.scheduler - DEBUG - Refreshing all scheduler timers
2024-02-06 21:35:39,813 - vorta.scheduler - INFO - Setting timer for profile 2
2024-02-06 21:35:39,817 - vorta.scheduler - INFO - Nothing scheduled for profile 2 because it would be the first backup for this profile.

:-) It seems that no automatic backups are executed after the import of the setting.

[real-yfprojects]

This is actually a change to the backup scheduler I implemented a while ago. Seems like it has the nice side effect to fix the problem of this discussion.

[goebbe]

Thanks for confirming that this behavior is expected. I will edit my first posts accordingly.

As a side effect it is always necessary to explicitly start backups manually to get automatic backups to work - e.g. after importing the .vorta.init.json file. This should probably be documented at: https://vorta.borgbase.com/usage/settings/