Skip to content
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

Daylight savings duplicate snapshots #36

Open
bdrewery opened this issue Oct 29, 2017 · 7 comments
Open

Daylight savings duplicate snapshots #36

bdrewery opened this issue Oct 29, 2017 · 7 comments

Comments

@bdrewery
Copy link
Owner

From @DimitryAndric

cannot create snapshot 'zcapsule/ca@zfs-auto-snap_frequent-2017-10-29-02h45': dataset already exists
cannot create snapshot 'zcapsule/git@zfs-auto-snap_frequent-2017-10-29-02h45': dataset already exists
cannot create snapshot 'zcapsule/springbank@zfs-auto-snap_frequent-2017-10-29-02h45': dataset already exists
cannot create snapshot 'zcapsule/tmb/coleburn@zfs-auto-snap_frequent-2017-10-29-02h45': dataset already exists
no snapshots were created
cannot create snapshot 'zroot/var/netatalk@zfs-auto-snap_frequent-2017-10-29-02h45': dataset already exists
no snapshots were created
@DimitryAndric
Copy link

This is really an edge case, and I just saw that there is already an option to use UTC for the timestamps:

    -u              Use UTC for snapshots.

So I'm not sure whether it is needed to create a workaround for this. It will happen only once a year :)

@bdrewery
Copy link
Owner Author

You suggested adding the TZ in on IRC, I like that.

@DimitryAndric
Copy link

Well, specifically the time zone offset, not the time zone itself. Or would zfs-auto-snap_frequent-2017-10-29-02h45-CEST and zfs-auto-snap_frequent-2017-10-29-02h45-CET be clear enough?

I think I'd like zfs-auto-snap_frequent-2017-10-29-02h45+0200 and zfs-auto-snap_frequent-2017-10-29-02h45+0100 better, but 1) it's a lot of extra characters and 2) I don't know whether plus signs are a problem in snapshot names?

@dlangille
Copy link

I suggest the server should be on UTC to avoid this issue.

@DimitryAndric
Copy link

I suggest the server should be on UTC to avoid this issue.

That is effectively the same as using TZ in the cronjob, or -u for the invocation.

What I'm suggesting is to make the names of the snapshots unambiguously usable even when the timezone is not UTC. For backwards compatibility, the existing names can be considered to be in UTC, while ones with added timezone suffixes are the "new" format.

@DimitryAndric
Copy link

Actually, I see that UTC based snapshots will already have an "U" suffix. So that at least takes care of that. Now as a user, my only question would be: "what happens if I switch to using -u after I have been taking snapshots for a long time without it?"

Also, I would suggest that the FreeBSD port at least changes its instructions to use -u, or even better, make -u the default, and provide an option to revert to the old behavior.

So the crontab part in README.md should become:

#### Crontab

    15,30,45 * * * * root /usr/local/bin/zfs-auto-snapshot -u frequent  4
    0        * * * * root /usr/local/bin/zfs-auto-snapshot -u hourly   24
    7        0 * * * root /usr/local/bin/zfs-auto-snapshot -u daily     7
    14       0 * * 7 root /usr/local/bin/zfs-auto-snapshot -u weekly    4
    28       0 1 * * root /usr/local/bin/zfs-auto-snapshot -u monthly  12

@brenc
Copy link

brenc commented Nov 2, 2019

Now as a user, my only question would be: "what happens if I switch to using -u after I have been taking snapshots for a long time without it?"

I just did this. The new snaps have a U suffix and the old ones get rolled out over time as usual.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants