zfs-auto-snapshot is creating snapshots on my backup pool about zfs-toolbox HOT 6 CLOSED

Yeah, I discovered this last night. Works like a charm. In case you haven't figured it out yet, zfs-auto-snapshot is set in /etc/cron.*, and I went through each of the scripts, adding the --default-exclude option.

from zfs-toolbox.

I'm wondering if there isn't a better solution that doesn't involve these somewhat complex manual configuration changes. 2 ideas:

(1) Be slightly more clever about matching the backup pool's snapshots to the local pool's snapshots, i.e., find the latest backup pool snapshot that is in the set of local pool snapshots, force rollback to this snapshot, and do an incremental send/receive from this snapshot to the latest local snapshot. Ignore the fact that the backup pool is also being auto-snapshotted, since these effectively get thrown away on every backup.

(2) At package install time for zfs-auto-backup (which doesn't yet exist), set up these configuration changes automatically by asking the user for the name of the backup pool and the local pool(s) to automatically backup. Use this information to change zfs-auto-snapshot config to add --default-exclude, and set the "com.sun:auto-snapshot" flag on all pools except the backup pool.

Any preference? I'm leaning toward (1). Seems simpler.

from zfs-toolbox.

I feel that (2) is the vastly better solution. Given that we're the only
people using this for now (and if anyone else is using it, then they'll
almost certainly be power users), I have no problem manually setting
properties on our pools and modifying cron jobs. When the day comes that we
need an install script, then that is they day we solve this in an automated
way.

I think that with (1), part of the problem will be recovery; it will just
be confusing why there are so many snapshots.

For now, I think we shouldn't worry about it, but maybe make a feature
request that we can deal with in the future.
--Joel

On Wed, Jul 11, 2012 at 9:00 AM, Matthew Finifter <
[email protected]

wrote:

I'm wondering if there isn't a better solution that doesn't involve these
somewhat complex manual configuration changes. 2 ideas:

(1) Be slightly more clever about matching the backup pool's snapshots to
the local pool's snapshots, i.e., find the latest backup pool snapshot that
is in the set of local pool snapshots, force rollback to this snapshot, and
do an incremental send/receive from this snapshot to the latest local
snapshot. Ignore the fact that the backup pool is also being
auto-snapshotted, since these effectively get thrown away on every backup.

(2) At package install time for zfs-auto-backup (which doesn't yet exist),
set up these configuration changes automatically by asking the user for the
name of the backup pool and the local pool(s) to automatically backup. Use
this information to change zfs-auto-snapshot config to add
--default-exclude, and set the "com.sun:auto-snapshot" flag on all pools
except the backup pool.

Any preference? I'm leaning toward (1). Seems simpler.

---

Reply to this email directly or view it on GitHub:
https://github.com/mfinifter/zfs-auto-backup/issues/4#issuecomment-6910923

from zfs-toolbox.

I think that with (1), part of the problem will be recovery; it will just
be confusing why there are so many snapshots.

Agreed. We'll proceed with (2). I'll file the feature request.

from zfs-toolbox.

Thinking about this more, (2) doesn't preclude (1). (1) might still be a good idea so that backups still work despite not having set up the configuration correctly.

from zfs-toolbox.

Lazy. Won't fix. Closing.

from zfs-toolbox.