On Apr 10, 2018, at 2:02 PM, Johan Ehnberg <jo...@molnix.com> wrote:
> Yes, this is quite feasible and straightforward to set up as long as you have 
> control over the selection of filesystem.
> Using a Copy-on-Write filesystem with snapshots allows you to very 
> efficiently replicate backups from the main server offsite. No rsync needed, 
> just 'zfs send' or equivalent tool for the selected filesystem. It will not 
> have to search for and detect the differences between the repositories like 
> rsync, instead it transfers the incremental changes from the filesystem since 
> last snapshot. Since the filesystem already keeps track of these, the effort 
> is minimal. You also have more control over the transfer data stream than 
> with rsync (read: multithreaded high compression ratio algos, use accelerated 
> VPN instead of SSH etc.).

 This seems like a possible solution to make a mirror disk set to put off set 
with rotation, wouldn't it?
 I've been thinking about this for a while, but have never had the time to 
deeply dig into tor test anything... Our system was set up with an XFS 
filesystem for the pool storage based on recommendations at the time, and have 
been thinking of how to dump that to a set of disks that could be taken offsite 
and used to rebuild a recovery server if needed.  Our original intention was to 
back up the pool with bacula or something to tape, but with v3 that wasn't 
workable, and don't know which is the better route to go now, but seems that 
the set of disks is not a bad idea with tape possibly another level, although 
as the pool size grows so does the tape requirement level... :)

 Thanks for the ideas.

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
BackupPC-users mailing list
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Reply via email to