On Sat, 2023-09-02 at 23:57 +0200, Linux-Fan wrote: > 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 > > öö > I have also been trying UpenMediaVault and it's an overkill for me.
I have a Dell R320 fitted with 8 1T SAS drives, the hardware raid is turned off as OpenMediaVault uses sorfware RAID. If I turn the hardware raid on can I use Debian as the opperating system? Thank you for any help, David.
