This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
We'd love to have a solution where a NAS312 is on premises A and an identical NAS312 is at premises B and they are, if not exact clones of each other then at least within hours of each other so that if site A is wrecked we can at least continue using unit B.
I am quite new to these products, the standard FAQs don't really answer what I need to know and I've tied myself up in knots.
What would I need to do to achieve the above scenario? No need to go into the WAN/VPN comms aspect as I'm OK with this, it is simply the ReadyDR/Rsync/Replicate feature set that quite frankly baffles me as to what does what.
For example, off top of my head, would it be an A to B rsync backup of shares that has complimentary ReadyDR running to do the snapshots on these shares too?
I was going to use a 2TB share size. The nightly full backup is (to use an easy figure) 200GB (of which in reality only 1 GB or less of data actually changes) and I was advised that I'd be lucky to get a week's worth of snapshots.
Does this ring true?
If the full backup is a single file, then rsync would rewrite the entire file - taking a fair amount of time over the network, and also shifting the previous nightly backup file to the snapshot (adding 200 GB to the snapshot space).
If the backup is large set of files, then only the files that changed are rewritten, and there is much less increase in the snapshot size. It'd be more than the 1 GB of changed data (since unchanged data in the changed files is also re-rewritten by rsync), but not the full 200 GB.
As a result I've created an iSCSI LUN of 1.5TB that the WSB will see as a dedicated device that it can indeed do incremental backups to, that I can also set to also snapshot nightly.
So, looking further, should the decision be made to get another offsite NAS for belt&braces purposes I'd use ReadyDR on this source LUN to a share on the offsite box???
ReadyDR generally works well for LUNs. Updates to blocks on the LUN on the source will increase the local snapshot size needed on the source of course. ReadyDR will migrate those changed blocks to the destination NAS efficiently.
How well this works with your software depends on how many blocks of the LUN are re-written when the WSB backup runs. If the WSB re-writes unchanged blocks, then it won't work very well. I'd try it locally first, and where you have more bandwidth to work with (and easier access to the destination machine).
If your goal is to mirror what's on the NAS, so you can quickly switchover to the backup:
-ReadyDR and Replicate won't do that. They will back up the primary NAS, but the destination repositories on the remote NAS aren't shares that you can immediately use. You'd have to restore them back, which will result in down time. And you will need enough disk space to do the restore (That is, you'd need enough free space on the destination to hold both the backups and the restored source shares).
-Rsync backup jobs will do what you want, but the snapshots won't match. (Note you can use snapshots on the destination, and you could then see older (backed up) versions of a file But the snapshots you see won't match).
The net here is that ReadyDR and Replicate are designed for backup, not "cloning". Like you, I am wanting cloning, so I am sticking with rsync.
One caveat: rsync is not great way to back up isci luns over the WAN. If you are using them, you probably do need ReadyDR, since it is only transfering blocks in the luns that have changed.
Thankyou, that is a great explanation for me on rsync vs everything else.
What happens with ReadyDR destination if the source is completely destroyed? I can't wrap my head around the "backs up snapshots only" idea. How can you recover only snapshots from unit B if the original is gone. As snapshots are only changes to the original over time, are these the snapshots that are created after an initial seed to box B of the LUN on box A for example? Otherwise I cannot understand how you can recover only snapshots when the original data is destroyed as they snapshots would have nothing to refer back to.
As snapshots are only changes to the original over time
Snapshots are trickier than you are thinking. Each snapshot actually includes the entire share as it appeared at the time the snapshot was taken. They are space-efficient because the data blocks that haven't changed are referenced by both the main share and the snapshot(s). So the space used by each snapshot is the delta, but the snapshot itself is a complete copy.
As far as ReadyDR goes, it uses btrfs-send and btrfs-receive (which you can look up). The destination is still complete when the source is destroyed (otherwise it would be useless as a backup). Because it is copying snapshots, you can roll-back to an older version of the share. You can take snapshots every hour on the source share, so you have some control over how much data is potentially missed when a failure occurs.
One benefit of backing up snapshots is that the backup is coherent (since files can't change while they are being backed up). You can also get this benefit if you run the rsync backup jobs on the source NAS. It will take a snapshot first, then rsync the snapshot (deleting the snapshot when the backup completes). But you lose coherency if you run the rsync backup job on the destination NAS.
Thank you so much for taking the time to respond to my enquiry and I think I am getting my head around this. I have received conflicting info recently over what snapshots are and what 'infinite snapshots' means.
I was recently advised to avaoid the following scenario that I was going to use in order to use Windows Server Backup (WSB) to a NAS box as a standard folder share destination. This would mean that each nightly backup would over write the previous night's one leaving only a 1 night retention and no incrementals (a sad drawback to using WSB on a network folder).
I was hoping, based on the infinate snapshots idea to simply take a snapshot after a nightly backup had been taken, thus allowing the new backup to be taken and having the snapshots provide a retention of sorts.
I was going to use a 2TB share size. The nightly full backup is (to use an easy figure) 200GB (of which in reality only 1 GB or less of data actually changes) and I was advised that I'd be lucky to get a week's worth of snapshots.
Does this ring true?
As a result I've created an iSCSI LUN of 1.5TB that the WSB will see as a dedicated device that it can indeed do incremental backups to, that I can also set to also snapshot nightly.
So, looking further, should the decision be made to get another offsite NAS for belt&braces purposes I'd use ReadyDR on this source LUN to a share on the offsite box???
I was going to use a 2TB share size. The nightly full backup is (to use an easy figure) 200GB (of which in reality only 1 GB or less of data actually changes) and I was advised that I'd be lucky to get a week's worth of snapshots.
Does this ring true?
If the full backup is a single file, then rsync would rewrite the entire file - taking a fair amount of time over the network, and also shifting the previous nightly backup file to the snapshot (adding 200 GB to the snapshot space).
If the backup is large set of files, then only the files that changed are rewritten, and there is much less increase in the snapshot size. It'd be more than the 1 GB of changed data (since unchanged data in the changed files is also re-rewritten by rsync), but not the full 200 GB.
As a result I've created an iSCSI LUN of 1.5TB that the WSB will see as a dedicated device that it can indeed do incremental backups to, that I can also set to also snapshot nightly.
So, looking further, should the decision be made to get another offsite NAS for belt&braces purposes I'd use ReadyDR on this source LUN to a share on the offsite box???
ReadyDR generally works well for LUNs. Updates to blocks on the LUN on the source will increase the local snapshot size needed on the source of course. ReadyDR will migrate those changed blocks to the destination NAS efficiently.
How well this works with your software depends on how many blocks of the LUN are re-written when the WSB backup runs. If the WSB re-writes unchanged blocks, then it won't work very well. I'd try it locally first, and where you have more bandwidth to work with (and easier access to the destination machine).
Hi Stephen, apologies for taking a day or so to reply. I have found your advice invaluable, however I may need to revisit this post once I have spoken to the project team here about this if that is OK.
