Backup using rsync of SMB shared datasets

[Rabuyik]

I'm creating a small bash script that will backup several datasets stored from my main raidz2 pool into some hotswap HDDs. The backup pools are stripe zfs and will be rotated offsite. Right now, I'm using rsync to copy all the datasets into one large backup dataset.

The source datasets have been created using the "Windows" permissions option as they're only used through SMB shares and nothing else.

Should the destination dataset on the backup drives needs to be "Windows" permissions as well (and also copying the .windows folder of each) or should it stays Unix on the receiving end ?

I'm questioning using "Windows" permissions everywhere for the data recovery scenario. If something happens, will I be able to easily rsync the data the other way around on a new freenas box / version / zpool configuration ?

Should I instruct rsync to NOT perserve permissions in order to facilitate this ?

 

[Ericloewe]

Why are you using rsync? ZFS replication is superior in every way, except for the fact that it's unidirectional and that it requires ZFS on the recv side.

 

[Rabuyik]

I have been using rsync to backup for a while because it works easily and I'm used to it from my old Linux habbits...

This is getting off topic, but I recently did try to upgrade my backup scheme to using ZFS send/receive of snapshots (as in this thread https://forums.freenas.org/index.php?threads/zfs-send-to-external-backup-drive.17850/ where you actually answered me). I ended up with some problem which I guess is related to the fact that I'm using encryption on all my pools. Each time I run the script (from the github link in the thread), the replication call crashes on a different dataset and the backup drive become UNAVAILABLE. I then need to reboot freenas or nothing works anymore (even the web gui stopped last time I tried).

 

[Stux]

That sounds like something which should be bug reported.

 

[Ericloewe]

Encryption cannot affect ZFS replication (after the pool has been unlocked), as they are completely independent layers.

 

[Rabuyik]

Thanks for the input. I suspect some hardware problem with the HDD I tried to replicate to.

As far as my initial question goes (and since I'm already set using rsync for now and until I figure my replication problem out), what would be the best course of action to reduce CIFS permissions problems in case of a recovery ?

Using rsync to arvhive each dataset on an identical dataset on the destination pool (both created using Windows permission) vs using rsync to archive everything on a single Unix permission dataset like I do right now ?

Thanks again!

 

[SweetAndLow]

Thanks for the input. I suspect some hardware problem with the HDD I tried to replicate to.

As far as my initial question goes (and since I'm already set using rsync for now and until I figure my replication problem out), what would be the best course of action to reduce CIFS permissions problems in case of a recovery ?

Using rsync to arvhive each dataset on an identical dataset on the destination pool (both created using Windows permission) vs using rsync to archive everything on a single Unix permission dataset like I do right now ?

Thanks again!

Permissions are going to be messed up no matter what. The windows dataset has acl that rsync can't deal with. I would try both and see which one allows you to recover easier.

Sent from my Nexus 5X using Tapatalk