Apparently I am unable to get Duplicati to compare two different versions of the backup of my choice; it will compare only the latest two versions. I have tried inputting in the integers that represents the version numbers I want into either right behind the target URL or together with the other options like --verbose but I can’t get it to work.
What’s the exact right syntax etc?
Thanks!
In the Commandline arguments text box, each argument must be specified at a separate line. Optionally, you can specify one or more advanced options here, also each option at a new line.
The Commandline arguments text box should look something like this:
Thanks, I will try this once this round of backups are done
EDIT: I have tested this and found it to be working
Meanwhile, what is the format of timestamps needed by Duplicati commandline?
C:\Program Files\Duplicati 2>Duplicati.CommandLine.exe help time
Duplicati supports absolute and relative dates and times:
now --> The current time
1234567890 --> A timestamp, seconds since 1970.
"2009-03-26T08:30:00+01:00" --> An absolute date and time. You can also use
the local date and time format of your system like e.g. "01-14-2000" or "01
jan. 2004".
Y, M, D, W, h, m, s --> Relative date and time: year, month, day, week,
hour, minute, second. Example: 2M10D5h is now + 2 months + 10 days + 5
hours.
C:\Program Files\Duplicati 2>
Showing it the above way because –time doesn’t say much. If you want something that says a lot, look at:
Time Formats for duplicity. Duplicati source shows that was its design target, but I think it has some bugs.
Thanks, I tried this too but I can’t get timestamps to accurately pinpoint which backup I was looking for. I tried using http://www.timestampconvert.com/ to get timestamp of the backups but they seem to be pointing elsewhere. E.g. If I input the timestamp for the day and time that backup 4 is complete, what got compared is backups 1 and 5 (not 0 and 4)
Playing with this here, there seem to be quite a few deviations from the documentation. When specifying only one of the two versions, I expected version 0 to be in the comparison, but got version 1 (same as you I think).
I can forgive the time format documentation a little more easily because it’s kind of generic and might not fit…
From a logic point of view, the compare interface taking an integer for either a version (0-based and small) or timestamp (big if it’s UNIX-style, and enormous if it’s C# style which is something like 100 ns ticks from year 1) raises the possible question of which was meant, but a heuristic could guess based on the size of the integer.
Putting in the exact local time string as shown on the Restore dropdown also works, and there’s an algorithm which tries to find the closest matching version time. Good thing, because seconds aren’t shown in dropdown. Unfortunately (perhaps, but read on) the time selector first tries to evaluate the value as a number. If it works, the value is taken as a version (which is wrong if you meant it to be ticks). If it fails, it evaluates value as date.
If it tried it as a date first, it looks sort of like the number would be interpreted as seconds before current time.
Would it be sufficient if you just fed in two small-integer version numbers? I don’t think integers as times work.
I willl be more than happy to use the small-integer version numbers, was just curious about the timestamps mentioned for the compare command.
Do these info about the timestamps apply to other commands that need timestamps?
That’s a very broad question which I can’t answer completely. Piece by piece comments follow. The “closest matching version” and the “evaluate the value as a number …” sections look like they are only in “compare” however some commands have similar documented allowances for less-than-to-the-second match, such as:
* `--time=<time>`
Restore files that are older than the specified time.
* `--version=<int>`
Restore files from a specific backup.
and you can also see how this and every other listed command besides “compare” uses a different option for the version-based and the time-based values, which seems like it would avoid the command having to guess.
I did try a short test of “restore” and it seemed to correctly interpret “11/13/2018 8:33:58 AM” local time which came from the output of the “list” command (which has seconds, unlike the Restore drop-down), and it made 1/13/2018 1:33:58 PM UTC internally, then couldn’t find anything at or before then because it had aged off… Retention policy that I had chosen bit me when I aimed for a tightly-spaced bunch of backups I’d used earlier.
The “seconds before current time” remark is possibly more widely applicable, except for direction which gets specified differently for different purposes. My “restore” command’s time=1555200 used 18 days after now.
You would be better off not relying on undocumented behaviors. This note doesn’t qualify as documentation. There aren’t often forum issues around --time, and its GUI even chokes on entry so I suspect it’s rarely used. Problem investigations and fixes will often focus around high-impact issues, so issues here may have to wait. Should you be exceptionally interest in testing (Duplicati does need testers…), Duplicati issues takes reports and is a better place to track them than in forum support posts, which are easy to lose track of when inactive.