-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add on hold snapshot feature #29
Comments
tested it by replicating to pool on external disk when external destination disk/pool is not present and I run and subsequent attempt to sync results with:
The "hold" would prevent it. |
ok I really need it:) so PR will follow soon |
Without holding snapshots when destination dataset is missing (example can be external disk) script can accidentally delete last common snapshot - as can not compare source and destination. The solution is to hold common snapshots using "zfs hold keep": https://www.thegeekdiary.com/understanding-holding-a-zfs-snapshot-feature/
@kapitainsky I missed this issue; sorry for keeping you waiting. This is very interesting and I'm happy to test and merge this if you are still inclined to create a PR. Same with other sensible changes you have made to your fork. 👍 |
Thx. I think PR is in waiting:) I am happy if you have any comments. I have been using my modified version and it works perfectly |
First - great simple script. Exactly what I was looking for.
At the moment finding common snapshots to protect them during pruning depends on both source and target datasets being present which does not have to be always the case and creates risk that pruning will delete last sent snapshot.
It would be great to add "hold" feature:
https://www.thegeekdiary.com/understanding-holding-a-zfs-snapshot-feature/
This way snapshot would be safe.
After successful sent hold can be removed and new snapshot marked as hold.
The text was updated successfully, but these errors were encountered: