Michael Kjörling writes: [...]
The biggest issue for me is ensuring that I am not dependent on _anything_ on the backed-up system itself to start restoring that system from a backup. In other words, enabling bare-metal restoration. I figure that I can always download a Debian live ISO, put that on a USB stick, set up an environment to access the (encrypted) backup drive, set up partitions on new disks, and start copying; if I were using backup software that uses some kind of custom format, that would include keeping a copy of an installation package of that and whatever else it needs for installing and running within a particular distribution version, and making sure to specifically test that, ideally without Internet access, so that I can get to the point of starting to copy things back. (I figure that the boot loader is the easy part to all this.)
[...]
My personal way to approach this is as follows:
* I identify the material needed to restore.
It consists of
- the backup itself
- suitable Linux OS to run a restore process on
- the backup software
- the backup key
- a password to decrypt the backup key
* I create a live DVD (using `live-build`) containing
the Linux OS (including GUI, gparted and debian-installer!),
backup software (readily installed inside the live system),
backup key (as an encrypted file) but not the password nor
the backup itself.
Instead I decided to add:
- a copy of an SSH identity I can use to access a
read-only copy of the backup through my server and
- a copy of the encrypted password manager database
in case I forgot the backup password but not the
password manager password and also in case I would
be stuck with the Live DVD but not a copy of the
password such that I could use one of the password
manager passwords to access an online copy of the
backup.
* When I still used physical media in my backup strategy
these were external SSDs (not ideal in terms of data
retention, I know). I partitioned them and made them
able to boot the customized live system (through syslinux).
If you took such a drive and a PC of matching architecture
(say: amd64) then everything was in place to restore from
that drive (except for the password...). The resulting Debian
would probably be one release behind (because I rarely updated
the live image on the drive) but the data would be as up to
date as the contained backup. The assumtion here was that one
would be permitted to boot a custom OS off the drive or have
access to a Linux that could read it because I formatted the
“data” part with ext4 which is not natively readable on
Windows.
In addition to that, each copy of my backups includes a copy of the backup
program executable (a JAR file and a statically compiled Rust program in my
case) and some Windows exe files that could be used to restore the backup on
Windows machines in event of being stuck with a copy of the backup “only”.
While this scheme is pretty strong in theory, I update and test it far too rarely since it is not really easy to script the process, but at least I tested the correct working of the backup restore after creation of the live image by starting the restore from inside a VM.
HTH Linux-Fan öö
Attachment:
pgpXpzKkZLEDS.pgp
Description: PGP signature