NAS Backup solution?

My NAS runs OpenMediaVault. It happens that mine is on a Raspberry Pi, but it's available (at zero cost) for many platforms. It's Linux under the bonnet, and the file systems in my case are ext4 - I can't imagine anyone would choose VFAT for use under Linux.

And rsync most definitely /is/ an option; I use it.

David

Neat. I personally use restic as my backup and don't want to risk breaking it, but its cool that it's a builtin feature of rsync!

I looked up OpenMediaVault, and it kinda looks like it is an Ubuntu spin optimized for media serving.

In my own case, I tend to just run a Fedora box, and let it serve media with Samba. And for that I use an (older, hence cheap) desktop tower. I don't quite see why one would buy a second box and allow that to only run file service. But if you did, what is a good hardware package to run it on?

It's a Synology DS115J box - the backups of my other devices go to 2 external USB drives which are formatted to EXT4.

I can access it via a browser, and it does allow me to install software on it, so I will investigate if there is anything available that will allow me to back up my Pi5 from that end.

Thanks for the various suggestions up-thread, BTW.

That's like asking "how long is a piece of string?" The answer depends on your needs. How fast? How much storage capacity? How much redundancy?

I don't need anything very fast, nor do I need lots of storage space, so a Raspberry Pi with two 1TB USB portable drives meets my needs. The second drive is updated from the first via rsync every day at 2am, which is enough redundancy for me. Other people scoff at this very modest NAS. Horses for courses.

David

I looked it up. It seems to be an ARM CPU in an enclosure that has only room for one drive. For a NAS, I would be looking for an enclosure that could hold 4 drives, but those are getting rarer. The secondhand market has plenty of small form factor desktops with low-end x86 or AMD64 processors and room for 2 drives for less than what this costs.

If you need to put the drives externally in a stack of USB enclosures, you might as well use an RPI4 in a CanoKit box.

I don't get the attraction of this type of device.

I’ve never found a use for rsyncd. All my network-based rsyncs have been point-to-point connections via SSH.

Regarding the --link-dest option, here’s how you might use it.

First backup:

rsync «options» «remotehost»:«dir» «local-backup-root»/«backup1»/

(This will be a full backup.)

Next backup:

rsync «options» --link-dest=«local-backup-root»/«backup1»/ \ «remotehost»:«dir» «local-backup-root»/«backup2»/

This avoids re-copying any files that haven’t changed since the previous backup, so the additional disk space needed would be the same as for an incremental backup. However, the clever thing is, the result still looks like a full backup for restoration purposes.

Typically the names «backup1», «backup2» etc will have a timestamp somewhere in them, as an obvious way to have unique names that also mean something.

And so on:

rsync «options» --link-dest=«local-backup-root»/«backup2»/ \ «remotehost»:«dir» «local-backup-root»/«backup3»/

When you get to 7 backups (or whatever your desired limit of old versions is), you can get rid of the oldest remaining one as you do a new one:

rm -rf «local-backup-root»/«backup1»/

and continue from there. Files that were superseded in later backups will disappear, while those that were not will remain.

I have a couple of old x86 boxes lying around which could be put to this type of use, but they're fairly large, and space is limited. Possible solution for future consideration though.

I've been using this one for years - the internal SATA HDD is only about

When I have a bit more time I'll look in to connecting the two USB drives to the Pi5 and see if I can use rsynch to make a manual backup for the time being.

Thanks for the suggestions.

I never understood the assumption that there is some difficulty with that question.

The answer is simple: hold it taut and measure the distance between the ends.

Not in comp.sys.raspberry-pi

-- “I know that most men, including those at ease with problems of the greatest complexity, can seldom accept even the simplest and most obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives.”

― Leo Tolstoy

I wouldn't recommend rsync:// protocol because it's unencrypted, although I suppose on a LAN there could be higher throughput for not having to en|decrypt data if your machines aren't particularly speedy.

Theo

I think Bitsavers offer it for those who want to grab a copy of their entire collections. That’s a public service, so no need for confidentiality. But authenticity would still be a requirement, that they’re hand-waving away for now.

I set up my backup system specifically for Raspberry Pi's using (at the time) unreliable SD cards, and making recovery to a new SD card as quick as possible.

Each time I create a new Raspberry Pi I set it up and then take a copy of the SD card with dd on to Networked storage. Each night this image is then mounted and rsync commands issued to update any changes files in each partition. That way if a card fails, I have a day old image I can dd straight to a new SD card and have the Pi backup and running. The only mildly involving bit was specifying the list of exclude directories of things which don't need to be backed up.

At the start or each week and month, I use zerofree on the latest image to clear any unused space so it compresses well with gzip, and keep those compressed versions in case any SD card corrupted creeps in to the daily image, so I can restore to a week or month ago if needed. I also keep the last backup before changing major OS versions in case of things like Bookworm updates causing problems.

All the stuff on the network storage is mirrored to several other on site and off site discs, again using rsync.

I've got nice graphs produced by the logs, so I can see that last night my 16 active Linux Raspberry Pi's backed up a total 1402MB of changed data in 2188 files in 425 seconds. The last time I updated the OS on all of them in May it was 25GB, 389,436 files in 1:01:04.

---druck

well, I have done this several times, so yes, you are wrong.

I backup all systems on a borg backup server. I boot from a usb stick and let borg restore from the backup server.

This can also be done with external hard drive of course. One just needs to save the encryption keys (if encryption is used).

But I see people here advocating the use of a hammer in all cases and being rude, only because one has a different opinion, so ... perhaps you try to learn something new that is more flexible and much better. And again - it is just my opinion from several years of experience with borg.

Example?

Example for what?

I already explained.

I backup all systems on a borg backup server. I boot from a usb stick and let borg restore from the backup server.

Do you mean example how to do it?

1. I do lvm snapshots of the running system and mount them to a directory (/backup)
2. I do the borg backup
3. umount and remove snapshots

I scripted this, so it is done automatically. Snapshots solve issue with changing files while system is running.

To restore (full restore - for example replacing disk after failure or whatever reason)

1. I boot from usb
2. I create the lvms and mount them (/backup)
3. restore from backup
4. (optional if disk is new) chroot, fix disk ids and install grub etc.

Deduplication and compression which are featured by borg make huge difference in the disk size side. It is about 1:10 or even higher ratio.

What happens if the file change is not complete when the snapshot is taken?

The purpose of snapshot is exactly to prevent this situation. Read about LVM snapshots.

But the snapshotting system has no idea what updates applications might be in the progress of doing to their data files.