Motivation: I have done some extensive looking through the code and development of a non-ssh based local backup that is appropriate for replicating a dataset to USB drives which are part of zpools and etc which can be physically taken off-site. I would like to use the built-in replication for this purpose (even losing some performance with SSH without encryption/compression, etc.). I am using replication to another FreeNAS server as one-level of backup locally and am trying to get a very low-bandwidth connection to work with an S3 based off-site backup. But, in order to do the USB based replication, I need to be able to run tasks (scripts, etc.) before and after the replication to import and export the pool containing the USB drives so that the USB drive can be removed without hanging ZFS for the USB pool.
Also, the USB local backup is only one of potentially 3 different replication targets for any one snapshot (USB, Local Backup FreeNAS, and off-site cloud).
Feature Requests:
(1) I suggest adding the ability for the user to specify and run a Pre-Replication Task and a Post-Replication Task that might run in jail or otherwise in such a way not to interfere with the replication. The task could be hooked to an existing FreeNAS Task, but modified so that it does not run in Cron, but on demand. If the Pre or Post Task fails, the replication task fails, otherwise the replication task continues.
Alternatively, in lieu of a full ability to specify an ad-hoc task, the user could be given a toggle option to "Import Source Pool Before Replication" and to "Export Source Pool After Replication."
In my USB example, the Pre-Task would check whether the USB-based pool was available to import because a USB drive had been connected by checking the list ("zpool import"); then run "zpool import USBPool". If the USB drive / pool was not available, the Pre-Task would fail and the replication task would not stop. The Post-Task in this example would check status and then do "zpool -f export USBPool" so that the USB drive could be disconnected cleanly.
Of course, the Pre / Post task functionality, if implemented generally, could be used for any purpose (to store additional user-generated state, do RPC calls, etc.)
(2) There appears to be a current restriction that only one replication can be made from any one snapshot. Based on a review of the code (especially the new workflow in the replication), it is not clear why such a restriction is absolutely necessary, even under the old workflow.
To overcome this limitation, a chain of replications is required which is very complex and error prone. For example, replicating to another server (or to a copy of the dataset locally) via ssh; then on the other server (or copy of the snapshot locally) creating a replication task to a different target (e.g. local USB or cloud-based FreeNAS instance, etc.)
I suggest adding the ability for user to specify multiple replication targets for one periodic snapshot. The implementation that seems to work is to add state information about the target(s) of a replication to either the periodic snapshot (via naming, user properties, or holds) or to state stored in the DB.
For example, I implemented this by use of hold tags such as "backup:drive1", "backup:drive2"; then releasing the holds as a new snapshot was moved to a certain drive; and not deleting the snapshot until all holds were released.
Also, the USB local backup is only one of potentially 3 different replication targets for any one snapshot (USB, Local Backup FreeNAS, and off-site cloud).
Feature Requests:
(1) I suggest adding the ability for the user to specify and run a Pre-Replication Task and a Post-Replication Task that might run in jail or otherwise in such a way not to interfere with the replication. The task could be hooked to an existing FreeNAS Task, but modified so that it does not run in Cron, but on demand. If the Pre or Post Task fails, the replication task fails, otherwise the replication task continues.
Alternatively, in lieu of a full ability to specify an ad-hoc task, the user could be given a toggle option to "Import Source Pool Before Replication" and to "Export Source Pool After Replication."
In my USB example, the Pre-Task would check whether the USB-based pool was available to import because a USB drive had been connected by checking the list ("zpool import"); then run "zpool import USBPool". If the USB drive / pool was not available, the Pre-Task would fail and the replication task would not stop. The Post-Task in this example would check status and then do "zpool -f export USBPool" so that the USB drive could be disconnected cleanly.
Of course, the Pre / Post task functionality, if implemented generally, could be used for any purpose (to store additional user-generated state, do RPC calls, etc.)
(2) There appears to be a current restriction that only one replication can be made from any one snapshot. Based on a review of the code (especially the new workflow in the replication), it is not clear why such a restriction is absolutely necessary, even under the old workflow.
To overcome this limitation, a chain of replications is required which is very complex and error prone. For example, replicating to another server (or to a copy of the dataset locally) via ssh; then on the other server (or copy of the snapshot locally) creating a replication task to a different target (e.g. local USB or cloud-based FreeNAS instance, etc.)
I suggest adding the ability for user to specify multiple replication targets for one periodic snapshot. The implementation that seems to work is to add state information about the target(s) of a replication to either the periodic snapshot (via naming, user properties, or holds) or to state stored in the DB.
For example, I implemented this by use of hold tags such as "backup:drive1", "backup:drive2"; then releasing the holds as a new snapshot was moved to a certain drive; and not deleting the snapshot until all holds were released.
Last edited:
