Backup Basics: via SMB or is this a 'Replication'?

[kiriak]

sending backups to a remote system and having the server to do this is the optimal solution,
but some home users like me do not have setup a second system plus secure remote connection somewhere else (not yet at least).
In this case rotating USB drives that are kept elsewhere is the next best solution.

In this case using a client machine to do the backups has some advantages
- it is easy and straightforward for less knowledgeable like me
- it easy for people without any knowledge to get access to the data (like my kids in case I go away)
- sometimes by doing it manually, it happened for me to spot mistakes, like missing files from the NAS, I mean files I forgot to upload to the NAS etc.

For me it is also a safety net in case I did configuration mistakes in setting up the snapshot replication.
So I use both snapshot replication and the client SMB methods.

@ChrisRJ
almost same backup here, I rotate 3 USB disks, 1 with replicated snapshots and 2 using the SyncBackSE program on a windows PC

 

[Patrick M. Hausen]

Even if I was rotating USB drives (which I think is a perfectly valid approach) I would have the server do it on autopilot (cron job) and just swap the drives every day.

 

[NumberSix]

Ok gang! (@Etorix @kiriak @Patrick M. Hausen), I finally bit the bullet and did a snapshot backup using the GUI. A requested the snapshots (from the top level ("NAS" pool) recursively, to my external USB connected drive. Both source and destination drives were of 8Tb capacity). It took 6 hours.

1) My question; I see an overall 5% discrepancy between the size of the source and the size of the destination. From the grab below you can see in detail that some elements in the Backup are smaller, while the iocage is larger! Inexplicable to me. That feels like, overall, something might be missing? Five percent's worth of data? Is this anything to be worried about, and does anyone know why the discrepancy is there? Thank you.

2) Going forward, next time I do a backup, in say a month's time, if I run another 'one off' (not scheduled) replication, specifying a full recursive snapshot, can I presume the system is smart enough to only replicate changes since the last backup, which will be few, hence to take substantially less than 6 hours in future?

3) And lastly, in the event of catastropic failure of TrueNAS, a restore is achieved - how? By importing the external drive, then... what exactly? Thank you!

 

[Etorix]

1) Are the pools of different geometries? Raidz is increasingly space-inefficient with small files, so size discrepancies are to be expected across pools of different geometries.
2) If the backup is based on recurring snapshots and there's a common snapshot present on the source and destination, the next replication job will be incremental from the last common snapshot.
3) To restore some files, mount a snapshot (from the GUI), and copy the file(s) back. To restore the whole set, replicate the backup in the opposite direction, clone the last snapshot and promote the clone. (Snapshots are read-only; "promotion" makes it an active, read-write, dataset.)

 

[NumberSix]

1) Are the pools of different geometries? Raidz is increasingly space-inefficient with small files, so size discrepancies are to be expected across pools of different geometries.
2) If the backup is based on recurring snapshots and there's a common snapshot present on the source and destination, the next replication job will be incremental from the last common snapshot.
3) To restore some files, mount a snapshot (from the GUI), and copy the file(s) back. To restore the whole set, replicate the backup in the opposite direction, clone the last snapshot and promote the clone. (Snapshots are read-only; "promotion" makes it an active, read-write, dataset.)

Hi!
1) The NAS is formed of 2 8Tb disks that I set up as a mirror, while the external USB connected drive is an 8Tb I was forced to set up as a stripe. All disks are Seagate Barracuda. Could the "mirror v stripe" be the two different 'geomtries' you speak of?
2) This is messy for me to try to answer as I don't know what TrueNAS was doing under the hood. At the time of replication, I was invited to make a new set of (from the top and recursive) Snapshots to replicate. I assumed it was therefore ignoring the many snapshots already on the NAS that are taken automatically at regular periods, and making a new set of copies especially for this moment. Both 'sets' (if there were 2 sets) being snapshots of the exact same thing - all my files and plugins, so if it was a 2nd set made especially for replication, then they should all be identical, except for their time stamps. However I don't know how TrueNAS behaves in this situation so I can't be sure if there's going to be "common snapshots present" as you mention..
3) You mention 'clone the last snapshot'; given that a recursive snapshot means a great many files, some with different dates, which one would i 'promote'? My guess is the very top level one ("NAS" in my case) and the one with the most recent date, if there's more than one on the backup?

Thank you for your thoughts, as ever.

 

[Etorix]

1) I was thinking about "mirror vs. raidz#", or "different level of raidz". A single drive vdev count as "mirror", so it's not clear where the difference comes from.
2) If you have a snapshot policy in place, you can use use these for replication. Just use the same name template in the replication task.
3) Whatever snapshot has the file you want to restore, the most recent being the obvious candidate for a full restore. "Clone" does not make a copy, it sets a point of divergence between the immutable snapshot and its clone, which can become a live, mutable, dataset. ZFS's CoW magic means that only the differences in the live dataset will use space in the pool.

You can experiment with your snapshots. Try mounting an old snapshot (read-only), and copying a file out of it on your desktop. Try cloning a snapshot—when you're done, destroy the clone. (Clones are like Number Two: You can have a new one for each episode.)