Best way to backup a small pool?

[NumberSix]

This is where I am right now; trying to work out how to save snapshots to a system other than the one they are on. My options as I guess them to be are saving my HDDs pool (called "NAS") to my SSD (called "System"), and vice-versa. Possible option 2, save these files to Windows 10?

I ran into a brick wall trying to zfs send the snapshots between NAS/System with the

Code:

zfs send System@systemApril29 > /mnt/archive/systemApril29
warning: cannot send 'System@systemApril29': signal recieved

result, which is hugely frustrating - I just don't know what it means or how to fix it, plus I can find no useful reference to it anyplace else.

So now I'm wondering if an alternative approach might be Replication via the GUI?

I wonder if I can use Replication as a way of saving snapshots to Windows 10? I explored the GUI 'Replication' area and of course it wants a source and a destination on different systems. I assume that since NAS and System are two pools on the same PC, these do not count as different systems, but clearly the Windows 10 machine (through which I administer the headless TrueNAS box, incidentally) is. However my attempt to specify the Windows machine and make a ssh connection (I have no experience of ssh) fail, with messages ranging from immediate no such destination to only slightly longer timeout messages. Am I wrong to think I can store the 'metadata' that is a snapshot on Windows until needed, or am I simply not addressing the Windows machine correctly - see attached screen grab? Related - if this connection is possible, is there a way to specify a destination folder on the target machine, or would that dialogue appear later in the process?

I have read that you can only use Replication if the target machine is running ZFS, but that snippet refered to a much earlier version of Freenas from a few years ago, and I'm wondering if perhaps I can at least send (but not activate) the snapshot data simply to be passively stored under Windows.

N.B. I changed the port number to 222 in testing since the default '22' proved impossible to open explicitly in the network hub.

 

[danb35]

have read that you can only use Replication if the target machine is running ZFS, but that snippet refered to a much earlier version of Freenas from a few years ago

Replication, by definition, is a ZFS-only thing.

 

[NumberSix]

So I can't backup snapshots using send. And I can't replicate snapshots unless I get a whole new NAS machine.

Is that checkmate then?

I feel there really really ought to exist a simple way to move snapshots off the hardware that created them. That seems somehow a profoundly basic requirement for a system whose raison d'être is to safeguard data, wouldn't you think.

 

[danb35]

So I can't backup snapshots using send.

You should be able to, not that it's a particularly useful operation:

Code:

root@freenas2[~]# zfs snapshot tank/files@now
root@freenas2[~]# zfs send tank/files@now > /mnt/tank/files_now_snapshot
root@freenas2[~]# ls -lh /mnt/tank/files_now_snapshot
-rw-r--r--  1 root  wheel    11M Apr 29 08:42 /mnt/tank/files_now_snapshot

I don't know why you're having problems, but I wonder if encryption might be a factor. But as I said, I don't think it's a particularly useful operation in most cases. If the goal is to back up data somewhere else that isn't running ZFS, rsync or one of the cloud sync options would really seem like the way to go.

And I can't replicate snapshots unless I get a whole new NAS machine.

...or pretty much anything else using ZFS. Or to another pool on the same machine.

I feel there really really ought to exist a simple way to move snapshots off the hardware that created them.

Replication is that simple way. But again, it is inherently a ZFS operation.

 

[Redcoat]

@NumberSix - take a look at this resource https://www.truenas.com/community/resources/how-to-backup-to-local-disks.26/

Perhaps you'll find something helpful there? Maybe you could use @Arwen's concepts with an HDD temporarily installed in your FreeNAS box, then removed and stored, for example?

 

[NumberSix]

I can't readily see why turning a snapshot into a backup by moving it to a separate device is not a 'a particularly useful operation' - perhaps it isn't for you depending on the hardware and software resources/options at your disposal, but for someone like myself on a very modest budget and trying so hard to safeguard against data loss, it feels like the only game in town right now if I want some sort of insurance against either of the hardware elements (HDDs or SSD) failing and needing replacement at some point, which most assuredly, will happen eventually.

EDIT: Scary last minute re-reading of what 'Replication' actually does; will this blow away the filing system on the target pool by using the snapshot involved to over-write what's at the destination, or is it just going to do what 'zfs send' does and store the snapshot in a new location, only via a GUI and to a schedule??!

 

[Redcoat]

You need to have the Synchronize box checked to allow "replication from scratch" and you need snapshots on the source.

 

[NumberSix]

@NumberSix - take a look at this resource https://www.truenas.com/community/resources/how-to-backup-to-local-disks.26/

Perhaps you'll find something helpful there? Maybe you could use @Arwen's concepts with an HDD temporarily installed in your FreeNAS box, then removed and stored, for example?

Thank you Redcoat. I can't fault the idea in theory, and the off-site aspect commends it. Alas, I can't do that in my particular case. I'm on a severe budget doing all this. That means I can't afford the extra HDD involved (mine is an 8TB mirror pool - man those disks don't grow on trees!), and that's without working around niggling little issues like the re-purposed motherboard I have with it's lack of free SATA points, underpowered PSU - the list goes on so I won't bore you. Lovely idea otherwise and I like the thinking outside the box (lame pun unintended) aspect to it. Thanks for thinking of it.

 

[NumberSix]

View attachment 46891

You need to have the Synchronize box checked to allow "replication from scratch" and you need snapshots on the source.

Hi Redcoat - thank you (again!) for that. However I just posted elsewhere in this thread:

Scary last minute re-reading of what 'Replication' actually does; will this blow away the filing system on the target pool by using the snapshot involved to over-write what's at the destination, or is it just going to do what 'zfs send' does and store the snapshot in a new location, only via a GUI and to a schedule??!

and I'm increasngly thinking that may be the correct interpretation of what it does. In which case - phew! I just saved myself from destroying some six week's work in setting the NAS up to this point by overlooking a couple of check boxes! That was close!!!

 

[Redcoat]

In which case - phew! I just saved myself from destroying some six week's work in setting the NAS up to this point by overlooking a couple of check boxes! That was close!!!

I don't understand what you you meant there. Replication takes the snapshots from the source and puts them into a destination location you specify. If that location doesn't have any snapshots in it, replication from scratch needs to be enabled with the Synchronize box check (if it isn't the replication fails as you found out).

 

[NumberSix]

I don't understand what you you meant there. Replication takes the snapshots from the source and puts them into a destination location you specify. If that location doesn't have any snapshots in it, replication from scratch needs to be enabled with the Synchronize box check (if it isn't the replication fails as you found out).

Hi
I may be very wrongheaded in this, but I was originally thinking that what can be done with 'zfs send (etc)' - storing, as a file, a snapshot onto a new location/system, was essentially the same was what Replication does. However, reading around Replication a little more, it seems to me that Replication does more than passively store a snapshot file to a destination - it looks like it effectively loads that snapshot over whatever data is in the destination - making the destination a sort of copy of the sending system. That isn't what I want to achieve at all! I am merely trying to find a way to store a snapshot somewhere so that if/when the system it references dies, a new disk can be purchased and installed, and the snapshot file can be used to rapidly get it back to where you were before the disaster.

I think Replication appears to be much more than a way of copying a snapshot between systems.

 

[danb35]

I can't readily see why turning a snapshot into a backup by moving it to a separate device is not a 'a particularly useful operation'

I think mainly because you can't do anything with it other than feed it back into zfs recv--you can't access individual files or directories, you can't mount it as a live filesystem, etc. If all you want is an opaque black box of a backup file, maybe this is OK for you.