The perfect Backup

This is, of course, subjective. It depends on your personal needs. I have the following requirements:

1. I have a Raspberry Pi 5 as a home server.
2. My clients are exclusively Windows PCs.

I have developed the following procedure for myself:

1. I back up my data to standard hard drives in an USB dock (no streamers, tape libraries, etc.). This is simply the cheapest way.
2. Since my clients are exclusively Windows PCs, I back them up at the share level, i.e., each root directory that my Windows clients see on the NAS is backed up separately (but several or all of them can be backed up on one disk).
3. But the Linux environment also needs to be backed up so that I don't have to set it up from scratch in the event of a catastrophic failure.
4. I use the hardware requirements as described in my Raspberry Pi GreenNas article. The scripts under Downloads (not available yet, this is a preview!) use the hardware extensions.

I have an encrypted partition (which is relatively large) on my server disk. To avoid having to copy it via dd or rsync every time, it is mounted on the backup disk and synchronized only at the file level. This requires entering the password during backup, so it cannot be done automatically (e.g., overnight).

All other data remains unencrypted, both on the server and on the backup drives. It contains nothing compromising or embarrassing, and I consider the risk of a (total) loss due to key-related issues to be higher than the risk of the data falling into unauthorized hands.

If you wish to encrypt your backup drives, you must implement this yourself. On the server, the data is permanently mounted and readable anyway, so having to enter a password during boot-up would offer no advantage.

The backup disk can be smaller than the NAS plus the server. It must already contain every share to be backed up (at least as an empty directory). This allows you to use leftover disks as backup media for one or more shares that fit on it.

It is therefore advisable to log every backup. I do this automatically in a database in the backup script. This way, I can always see which disk contains the most recent backup of a share, or which shares haven't been backed up in a while, which I'll need to do soon.

The backup disk is identified by its UUID, has a unique name in the database, and is labeled with this name (and the UUID, just to be sure).

The script backup.pl backs up the SSD on the NAS drive. This script is usually run more frequently and protects against SSD failure or accidental deletion. If something goes wrong on the server, the data on the NAS drive is completely preserved.

The NAS disk is much bigger than the SSD and can easily hold its comtent.

Finally, the script rsyncNas2Backup backs up the contents of the NAS drive, or parts of it. Each directory to be backed up must already exist on the backup drive; otherwise, it is skipped. The backup is then saved to an external drive. This external drive is regularly rotated, so that several drives of varying ages are available offline for restoration.

Unimportant until you need it!

Of course, you know where the latest backup is. But what about the hard drive in the kitchen cupboard? When was the one on the basement shelf? What exactly is on it?

It's a good idea to hide several backup drives in different locations around the house (or better yet, in another house, at a friend's house, or at your workplace) so that a burglar can't sell them all together for a pittance and leave you back with nothing.

I sometimes use smaller (leftover) hard drives, each of which only holds a portion of the backup. Using the database, I can quickly see which shares I need to back up shortly and which drive might be suitable.

My database contains two tables for this purpose:

• A table called tMedia that includes every known medium (local hard drives as well as backup drives). Each partition on the media must have a label.
  New, previously unused backup drives are automatically detected and added to the database.
  Changes of local disks may be entered by backupUpdateMedia (see downloads).
  The script "updateMediaDB" also determines the manufacturer, model, size, and serial number of the drive, if this data is available, and stores it accordingly.
• A table tBackup logs each backup, i.e., when, which share was backed up from which medium to which other medium, along with an error code indicating whether the backup was successful or why not.

Uniqueness of UUIDs is essential! Cloning hard drives using a simple (dd) copy is strictly prohibited. This can also lead to problems elsewhere and should never be done!

• UUID is the UUID of the file system of a partition.
• PARTUUID is unique for a partition of the disk.
• PTUUID is the UUID of the partition table, so you can consider this as a UUID identifiing the disk itself. It is common for each of the partitions.

Finally, set a meaningful name, e.g., e2label /dev/sda1 DiskName, under which it will later appear in the database. This is neccesary. An empty name (null) is not valid in my database and it would result in an error on insert!

Mount the partition in /backupdisk and create an empty directory for each root directory of the NAS, that will later be backed up to this disk.

It is now available for rsyncNas2Backup.

The disk's data is automatically entered into tMedia during the first backup, and backups are also logged in tBackup without any further action required.

A key question here is: "Why do I need a restore?"

There are at least three scenarios:

This situation is still relatively straightforward. Simply activate the NAS and copy the affected files back. If they're no longer there either, hopefully you have a suitable older backup disk.

This isn't an insurmountable problem either. Replace the SSD and/or the server, and in the worst-case scenario, reinstall the server. Install all the packages you added back then (you surely wrote that down somewhere 😉). Copy the files in /etc and the other files from the last backup, and everything should largely work again.

You've caught a virus that has encrypted your data.

Now you have a problem!

The best-case scenario would actually be that it's on your server. Then you can reinstall it from a safe source, copy the files in /etc and all shares back, and everything will be OK again.

But it could also be lurking in one of your clients, perhaps having already spread to others...

Now you need to check your entire network, possibly perform reinstallations, and make sure they don't get infected again. I wouldn't want to be in your shoes right now!

From now on, keep all your backups! It may have been lurking for weeks or even months without showing any signs of infection, and could strike again weeks after a seemingly successful restore. An older backup might be your salvation!

Do not use backup disks directly! Make a copy on a secure system; otherwise, it could also infect older backups!

It can't hurt to practice an emergency scenario, such as restoring data from a backup drive to a new NAS drive or from the NAS Backups directory to a new Raspberry Pi 5.

This isn't really expensive (you'll need another hard disk or another new Pi5), but it reduces stress later on when things really get serious!

And thanks to this exercise, you will already have the spare parts ready at hand. Remember: a real emergency will inevitably strike on a Friday afternoon when you can’t order anything until Monday...