Script will have problems when zfs-auto-snapshot deletes snapshots about zfs-toolbox HOT 7 CLOSED

Yeah, this will be a problem. We could augment zfs-auto-snapshot to record its renamings so that we can replay them on the backup drive and then proceed as normal. Or, if it is straightforward/deterministic enough, just repeat the renamings ourselves on the backup drive before doing anything else.

The other option is to just have backups take longer than they should because the incremental "from" snapshot will reach back to a weekly or monthly or something instead of a more recent one that has been renamed. But I could imagine scenarios where basically everything has been renamed, so doing an incremental won't even be an option.

from zfs-toolbox.

Okay. Here's an idea on how to fix this. Please let me know if you think this will work, or if you see a problem.

Instead of looking for a particular snapshot, the zfs-auto-snap snapshots have a particular naming format. Namely, they all look like: dataset@zfs-auto-snap_TYPE-DATE-TIME

So, once we determine that the last snapshots are not the same, what we really should do, is grep through the zfs list to find the snapshot that contains the DATE-TIME, but not necessarily the TYPE. After we find that, we would do an increment from there to the most recent snapshot.

Of course, if the last snapshot in the backup was not a zfs-auto-snap, then we should just do an incremental from there, forgetting all the other business.

from zfs-toolbox.

On Sun, Jul 15, 2012 at 8:06 PM, Joel Weinberger <
[email protected]

wrote:

Okay. Here's an idea on how to fix this. Please let me know if you think
this will work, or if you see a problem.

Instead of looking for a particular snapshot, the zfs-auto-snap snapshots
have a particular naming format. Namely, they all look like:
dataset@zfs-auto-snap_TYPE-DATE-TIME

So, once we determine that the last snapshots are not the same, what we
really should do, is grep through the zfs list to find the snapshot that
contains the DATE-TIME, but not necessarily the TYPE. After we find that,
we would do an increment from there to the most recent snapshot.

i.e., compare, ignoring the TYPE. SGTM.

Our script should be 100% ignorant of the type, I think, because from the
perspective of backups, this information is not useful. Backups care about
the exact snapshot. Idea: is there a unique snapshot id? Can/should we
use the value of the snapshot's 'creation' property (i.e., timestamp of
creation of dataset)?

Of course, if the last snapshot in the backup was not a zfs-auto-snap,
then we should just do an incremental from there, forgetting all the other
business.

Maybe it makes sense to have more separation of logic related to which type
of snapshot (i.e., auto-snap vs. named) we are dealing with? But yes, sgtm.

You planning on implementing this?

• Matt

from zfs-toolbox.

Yeah, I guess I'll be in charge of this one. This stuff is getting complex fast.

from zfs-toolbox.

Another thought about how to approach this. Have you seen https://github.com/adaugherity/zfs-backup ? It makes two assumptions:

1. You do your own initial backup
2. You setup your backup script to run regularly. If you do not run at a regular interval, it will not work.

This is important because it runs often enough that the last backup you made will not be so old as to be non-existent because of renaming.

Do you think this is reasonable enough for our purposes? Are you willing to setup your system under those assumptions?

Update Honestly, https://github.com/adaugherity/zfs-backup seems to do a lot of what we're trying to do, albeit in BASH. We might consider just forking that project.

from zfs-toolbox.

Yeah, this all makes sense. Does that project do everything we want?
Should we just be using that and forget about this project? Or does it
only do remote backups and not local ones? Even if that's the case, it may
be easier to just fork that project and add local backup functionality.

On Tue, Jul 17, 2012 at 9:28 PM, Joel Weinberger <
[email protected]

wrote:

Another thought about how to approach this. Have you seen
https://github.com/adaugherity/zfs-backup ? It makes two assumptions:

1. You do your own initial backup
2. You setup your backup script to run regularly. If you do not run at a
   regular interval, it will not work.

This is important because it runs often enough that the last backup you
made will not be so old as to be non-existent because of renaming.

Do you think this is reasonable enough for our purposes? Are you willing
to setup your system under those assumptions?

---

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

from zfs-toolbox.

It just works for remote backups, although, obviously, we could change that easily enough. But it's written entirely in BASH, so as far as I'm concerned, it's not maintainable or modifiable, so I think there's still value in our project.

from zfs-toolbox.