Suggestion for a reliable low powered SBC NAS for photos and documents backup

Have you considered a second disk and Rsync? Rsync backup is simple to set up, and to restore, and can be used to backup an entire disk. (I'd call it a delayed write mirror, that's similar to RAID1, but also functions as a backup.) Rsync works fine on an SBC and, with the Remount Plugin, an Rsync job can be set up to store data on another host (or SBC).

If you want to preserve certain shares, that could be done with rsnapshot which provides versioned backups using snapshots. (You could restore from yesterday, last week, a few months back, etc.) While this a superior method of backing up important data, it's not well suited for frequently changing data sets.

So what do you want to backup?
A full disk?
A network share? (Size?)
___________________________________________________

If going from OMV to OMV, on a local LAN, I can help you to set that up. I haven't set up a VPN, to go to an offsite location, so I can't help you with that.

Well, note that using an R-PI with more than one disk would be taking a serious risk. The R-PI is in it's own category, due to it's poor combined USB/Ethernet interface.

However, other better performing SBC's can be used with more than one disk. A general rule of thumb is, don't attach more disks than the SBC has in ports and don't expect an SBC to power up more than one 2.5" spinning disk through the USB interface.
______________________________________________________________________________

Your backup scenario looks fine. The bottom line is, have at least two copies of critical data, with three copies preferred. It's also better to have at least 2 platforms involved, meaning if one SBC and drive dies, you have another SBC and drive with identical data. Getting back on-line is fast. It's just a matter of switching to a new server.
______________________________________________________________________________

- If you want to do a drive-to-drive Rsync copy (locally), you'll find how to set that up -> here, starting on page 60 (of this version).

- If you want to copy data to another host, you'll need to install the Remote Mount plugin. There's a couple different ways this can be done.

My preference is, at the source (the main server):
Set up your own system user, give that user a password, and at least read access to a network share. (The user name can be anything but do not use "backup". "backup" is a default Linux system user name. Use something like backup-1.)

At the destination, install remote mount. To set up a new mount, use the IP address of the source server, the name of the share, and use your system user and password, with at least read access, to the share you're mounting. When complete, your Remote Mounts might look something like this. (When naming them, add something that shows the name of the source share and that they're remote.)

______________________________________________________________________________________________

If successful, you'll see the a new file system under Storage, File Systems. In the following note all file systems with cifs are from the remote source server and that their names have _R_ in them. The names with _R_ in them, help me to identify that they're remote , not local.

___________________________________________________________________________________________

Next I set up shared folder "pairs".
Note, in the following, one share for Backups is local and the other is remote. Also note the relative paths. The path Backups/ is correct for a local shared folder. However, when selecting the device (which will be the file system mounted with remote mount) the relative path will be auto filled with something like Backups_R_OMV/. This is wrong. it must be changed to /

Finally, the following are what I call "Rsync" pairs. When setting them up your Rsync Jobs, note the type is LOCAL. (Why? Remote Mount is making the remote share appear to be local.) The source shared folder is from the Remote Server and the destination shared folder is to a local folder.

In setting up the Rsync jobs above, I set the following options ON (the button is green):

Recursive
Times
Archive
Delete (Make sure you have the source and destination right, before turning this switch on!)
Preserve Permissions (This switch doesn't actually work, with files sourced from a foreign volume.)
Preserve Extended Attributes (Do not use this switch with if data is sourced from a ZFS pool).
Keep Partially Transferred Files

I use the following in the "extra options"
--chmod=0755 --chown=root:users

Without the above, in extra options, only the root user will have access to files at the destination. Since I have a second server on line at all times, I set the same share permissions, that are on the source, at the destination server.
___________________________________________________________________

While there's work involved in setting it all up, the above processes can be used to replicate all of your primary servers shares to another server. On the Rsync schedule, since a data disaster can be replicated to a second server, I'd set the job frequency to be no less than 1 week and you might want to think about making it two weeks. This will give you time to turn replication off if there's a major data loss on the main server.