Implement snapshotting with something similar to systemd timers

[ethanjjjjjjj]

It would be nice to have snapshots automatically created as soon as possible after one was missed. For example after a reboot, the system may have been off for 6h yet may still have to wait almost an hour before the next snapshot. I think with this it makes sense to give the option to include a specific number of snapshots rather than a time period, if a system is off for a long period of time it will be booted and have all its snapshots deleted.

[jimklimov]

Interesting idea; I suppose this can be hacked into ZnapZend.pm $createWorkers() routine where it decides to work instantly for --runonce mode or set a timer otherwise. Perhaps check the newest snapshot age and decide if it is more than the policy interval for this backupSet - then do like runonce (note if you don't actually have the runonce flag set, then the callback will set the new timer after re-evaluating when it should fire... anyhow the run can take a while and chew into precalculated time slot).

[jimklimov]

@haze458 : With the current state of master branch, I think there are some differences to what you describe:

• ... if a system is off for a long period of time it will be booted and have all its snapshots deleted => this should not happen at all: znapzend should not delete snapsets from name-patterns it did not make ;) if you have replication set up to send snapshot to a remote destination, it should not clean up sources (nor destinations) until a resync succeeds with a newest just-made snapshot; znapzend should not delete a most-recent snapshot (usually the one it just made in this run), though it can clean up the earlier snapshots indeed; since this summer, znapzend should track which snapshot is the newest one successfully sent to this or that destination, and such newest snap should also not be deleted as required for resync, if the destination is currently offline or diconnected (e.g. USB disk).

• makes sense to give the option to include a specific number of snapshots rather than a time period => mathematically, if you say that "for most recent 6 hours I want hourly snapshots, then for most recent week I want daily snapshots, etc." this sort of dictates the amounts to keep at each frequency, and quite flexibly. I agree it may be hard to precisely predict how many would be there, e.g. with a "2h => 1h" schedule I usually see 3 not 2 snaps, one being nearly 0 seconds old and the older being 2h at the time the script checked, but it's pretty close :-D

• It would be nice to have snapshots automatically created as soon as possible after one was missed => I read this as "if daemon-mode was just started, and a schedule wanted e.g. hourly snaps, and the newest one was more than an hour ago, make one instantly and don't wait for next HH:00", right?

• For example after a reboot... => would a solution less smart than in the line above help, to extend a sort of --run-once option for daemonized mode, so that with a special CLI flag, whenever your znapzend service starts, it would make and send the snapshots as soon as it can, possibly with no-destroy mode for this first run, and then would proceed to tick by wallclock schedule? So then this fires regardless of when the previous newest snap was - with a reboot, it could be 5 mins ago... but the loader/updater could already mess up the filesystem so you'd want to keep that pre-reboot snap for quick rollback and not delete it just now but wait to do so until scheduled run in the daemon...

[marshalleq]

Along this same line, I'm looking to see if the starting time could be randomised. What I mean is, rather than kicking off 10 daily backups all at midnight, maybe to offset them to reduce system load?

[jimklimov]

I'd say in the latter proposition, there are two different timings. One is making a snapshot at midnight wallclock time and writing in the label that it was midnight. That is a relatively cheap operation usually, and can be done when the timer strikes.

A separate effort, that may make sense spreading over time, is the running of backups to remote destinations. Note that not everybody has that mode at all, many users just run znapzend to keep an array of snapshots that expires to be more and more sparse over time long ago. Reminiscent of RRDB in MRTG somewhat, huh? ;)

This may be achieved, I think, by some toggle to limit the amount of backupSet driven schedules that can run simultaneously. For datasets covered in one schedule, the replication is sequential, but several schedules can run in parallel. Given that with many enough snapshots they are mostly waiting for info from recipient ZFS to see which snapshot GUID the next increment attaches to, so say a minute without I/O and a seconds-long splash to write the bits, I locally am in favor of having as many such in-flights as possible. But surely YMMV.

On Tue, Dec 15, 2020 at 12:49 AM marshalleq notifications@github.com wrote:

Along this same line, I'm looking to see if the starting time could be randomised. What I mean is, rather than kicking off 10 daily backups all at midnight, maybe to offset them to reduce system load?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/oetiker/znapzend/issues/488#issuecomment-744827330, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFAGLA3KP22THVLC2V3SU2P7XANCNFSM4NRCEMFA .

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.