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 backup. So this is all about restore in a worst case scenario.

In other cases restore is much easier. If, for example, you just want to restore a file from yesterdays backup on your computer, it is sufficient to open Vorta, go to Archives, mount the archive from yesterday, browse yesterdays 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 9.1 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/stole/destroyed computer. You used Vorta for backups on this computer
remote-backup-server - the server that has been used to backup 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 base as follows:

1. 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 can restore:

• 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!)
• Use borg key export to save a backup of your key-file ,see f), in a password manager.
• Save the passphrase of your repo and the info required to access your account at your-backupserver.org, see g) in a password manager.
• 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 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 you repository, use borg key import to import the backup of your keyfile for your repository.
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 keyfile and you don't plan to use the restore-computer to access the repository in the future, you should delete the keyfile from the home directory (~/.config/borg/keys) after restore.

edit: Add requirements about "keyfiles".
edit2: Clarify, that borg key export/ import has to be used for the keyfile

[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 - to avoid accidental manual backup? (may not be desired)
• Check if Vorta can ssh to the remote-backup-server and give feedback:
  • either: ssh is already setup, then give feedback and - NEW: 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 of course fine - however it could lead to wrong conclusions. Automatic backup will not be executed automatically. So there is not 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/