Specify the date and time of the backup

[danwilliams]

This might seem a little odd, but is very useful when migrating backup sets from other software. For instance, I recently converted a huge set of tgz files to Bup, and specified the date and time for each, thereby recreating the backup history. It doesn't have much use outside of this scenario, but would allow migrated sets to play nicely with the attic prune command. I imagine it's also a fairly simple addition.

_Comparison note__: Bup and Obnam both allow this._

[camh-]

This is a fairly simple addition and I've got a patch ready that does it.

I've added a --timestamp option to the create subcommand. The reason for and not a timestamp string is that I realised when importing old backups, I was just taking the timestamp from the root of each snapshot I had, and I had no use for an actual timestamp as a string.

Do you think a timestamp string (YYYY-MM-DD HH:MM:SS) is useful to you? I'm deciding if I add a simple heuristic to try to parse the argument as a timestamp string if it is does not reference a valid file.

[ThomasWaldmann]

What do you mean precisely by "taking the timestamp from the root"?

Having a specific timestamp seems useful. Yes, use iso-like time format for it.

[jdchristensen]

I agree that this is a useful feature, and that being able to take the timestamp from a file or from the command line would both be useful. But rather than a heuristic, I think different command line switches should be used.

It would also be great if you could specify times flexibly, like the date command allows.

[camh-]

What I mean by "taking the timestamp from the root" is that if you are importing an existing backup from the filesystem (i.e. untarring the tgz mentioned in the original comment), the root of that tree will have a timestamp that is the timestamp of the backup. Or the timestamp of the tar file itself. Using the mtime of the directory or the tar file as the backup timestamp is all that is needed.

That is, any decent backup is going to have the timestamp that backup was taken on it. You may as well just take the timestamp from that rather than require a cumbersome manual entry of the time (and risk mis-entering it).

So, I'm looking for more than "useful". Code needs to have use case, I don't yet see one for manually overriding the timestamp. Time/date parsing is horrible and error prone (I don't want to think about the timezone handling part of it - it will just make me cry), that I'd rather avoid it unless there is a strong use case.

[ThomasWaldmann]

You are assuming mtime properties of the root directory which are not necessarily true.

Thus, we need a way to specifically give the datetime as a string and alternatively get it from a file or directory mtime (in cases this makes sense).

About the datetime string parsing my POV is to only support iso-like format. 2015-04-14T01:26:59 (and tolerate a blank instead of the T). That's what ISO standards are for, to have an international standard. And it even is the most logical and most practical way.

[camh-]

By "root" directory, I meant the root of the tree being backed up, not the root of the vfs namespace (/). Sorry for the confusion.

Essentially it is any file/directory that can be the source of the timestamp, and in my example, it was the root of the directory tree being imported. In the original comment, it could be the tgz file containing the backup.

With a timestamp string in ISO-like format, the timestamp would be in UTC, yet the output of 'attic list' shows local time. This is rather unfriendly and error-prone (most people think in local time and if they have to manually convert to UTC, mistakes will be made).

I originally started implementing timestamp string parsing code but came to the realisation that all use cases I could think of were covered by using a file/directory as the source of the timestamp, which was also easier, more accurate and less error-prone. This is why I am asking for timestamp-as-string use cases.

[evanhempel]

When I imported my data into attic, I had a bunch directory snapshots where I would have used the timestamp function if it was available (I didn't trust the directory mtimes).  My workaround was setting the system time then running attic for each timestamp.  Count this as another vote for accepting an ISO timestamp option (optionally with timezone information).

Sent from Yahoo Mail on Android

From:"Cam Hutchison" notifications@github.com
Date:Mon, Apr 13, 2015 at 7:43 pm
Subject:Re: [attic] Specify the date and time of the backup (#263)

By "root" directory, I meant the root of the tree being backed up, not the root of the vfs namespace (/). Sorry for the confusion.

Essentially it is any file/directory that can be the source of the timestamp, and in my example, it was the root of the directory tree being imported. In the original comment, it could be the tgz file containing the backup.

With a timestamp string in ISO-like format, the timestamp would be in UTC, yet the output of 'attic list' shows local time. This is rather unfriendly and error-prone (most people think in local time and if they have to manually convert to UTC, mistakes will be made).

I originally started implementing timestamp string parsing code but came to the realisation that all use cases I could think of were covered by using a file/directory as the source of the timestamp, which was also easier, more accurate and less error-prone. This is why I am asking for timestamp-as-string use cases.

—
Reply to this email directly or view it on GitHub.

[camh-]

I should also add my other thought about timestamp strings: It is possible to 'touch -d ' on the root of the tree you are importing, and then use that directory as the timestamp source. This is not that friendly, but it does serve to make all cases possible. touch(1) has a very flexible timedate string format too.

To address an earlier comment by @jdchristensen, I am against having multiple flags (one for timestamp from file mtime, another for timestamp as string), as I think it bloats the interface too much. I'm a fan of "keep it simple". It's reasonably easy to differentiate between different types of argument values, so I'd prefer to do that.

If anyone is interested, my working copy of this is https://github.com/camh-/attic/commit/5cce7c1de7b3b6be88b9ca12b78d517d582dba3d

[adept]

If you consider using "touch -d", you can use faketime as well. And when
faketime or touch are not easily available or not feasible it would be nice
to have a commandline switch

On Tue, Apr 14, 2015 at 1:53 AM, Cam Hutchison notifications@github.com
wrote:

I should also add my other thought about timestamp strings: It is possible
to 'touch -d ' on the root of the tree you are importing, and then use that
directory as the timestamp source. This is not that friendly, but it does
serve to make all cases possible. touch(1) has a very flexible timedate
string format too.

To address an earlier comment by @jdchristensen
https://github.com/jdchristensen, I am against having multiple flags
(one for timestamp from file mtime, another for timestamp as string), as I
think it bloats the interface too much. I'm a fan of "keep it simple". It's
reasonably easy to differentiate between different types of argument
values, so I'd prefer to do that.

If anyone is interested, my working copy of this is camh-@5cce7c1
https://github.com/camh-/attic/commit/5cce7c1de7b3b6be88b9ca12b78d517d582dba3d

—
Reply to this email directly or view it on GitHub
#263 (comment).

Dmitry Astapov

[danwilliams]

I agree with specifying the timestamp as an ISO-standard string. Timezones should not be an issue as they can be specified as part of the string. I do not like the idea of magically taking the time from directories or files, for reasons already said (too much assumption, may be incorrect).

@adept Unfortunately, faketime doesn't help me much when backing up to a remote repository... hence the need for a command line switch, plus the ability to do this without external dependencies.

[camh-]

@danwilliams, there's nothing magical about it. You take the mtime from the file explicitly specified to the given option. There are no assumptions

Any backup of reasonable fidelity is going to have a container that has the timestamp of the backup (whether that container is a directory, a tarball, a log file, etc).

Can I ask where people who want a timestamp string are actually getting their timestamp from?

BTW. If you really want to follow the ISO standard (ISO 8601), note that "2015-101T24" is a valid date string. Plus multiple other variations. ISO also does not have timezones, only UTC offsets. You need to know yourself whether a particular date/time was during daylight savings and apply the appropriate offset yourself. Not particularly user-friendly.

[danwilliams]

@camh Sorry, I was referring to the idea put forward at one point about taking it from a base folder. I didn't like that much. Taking it from a specified file seems fine and non-magical, but not in place of specifying a string, only as an alternative.

Personally my timestamps come from the date the backup was made. It is possible that nothing has changed inside the filesystem for some time, so if you do subsequent backups it would be odd if they magically came out as the same date.

I don't see any timezone issue because if I ask the system for the date of a file, including timezone (offset, not named) then I can simply pass this along. This is what my existing conversion scripts already do. So that all sounds fine to me, no biggie.

[ThomasWaldmann]

See PR #285.