I’d like to run a check after every backup but it should only check the latest revision, not all of them. Is there any way to achieve this? If not, please make this a feature request.
I have tried to work around this by having backup set the tag “unchecked” and then limit prune to that tag, but I can’t seem to find a way of removing a tag (which would need to be done after the check.
I used a “workaround” with batch files in 3 steps:
for /f "tokens=*" %%a in ('dir Duplicacy*.log /b /o-d /a-d 2^>NUL') do set last_log=%%a
for /f "tokens=1,2,3,4,5,6,7,8,9,10,11,12,13* delims= " %%m in (!last_log!) do (
if "%%p"=="revision" set "var_rev=%%q"
)
check with the revision found.Not the most elegant way, but it works!
(I really have to find time to make a revision on my scripts and make them more parameterized, well coded and “presentable” … 
)
It would also be very useful for operations that expect revision number to accept a string such as “newest” or “latest”, similar how darwinup handles it on macOS.
duplicacy backup
duplicacy list -r newest -filesi think the parameter should be -last, since that is its use: address the last revision.
I was thinking about using negative numbers, like -1 for the latest, -2 for the second latest, etc. But I don’t know if all these negative numbers other than -1 are useful. If not, maybe we should just use last or newest.
last is definitely more userfriendly than negative numbers.But I see that it would be easier to implement.
The only way numbers would make sense is if they can be used to count revisions backwards: -1 would be the newest revision, -2 the second newest, -3 the third newest and so on.
If you decide to implement it like that, I’d suggest to simply define -r latest as an alias for -r -1
This feature would be very useful. I’m using Nagios to monitor how long it has been since the last completed backup. At the moment my script has to list all backups and then get the time of the last one, and this can take many tens of seconds.
I also think having -1, -2, etc. is not that useful. (maybe even call that unintuitive) When checking my stuff, i generally tend to look either at the last revision, or do a listing of all the files in all the revisions.
imo just having -last (and not -latest since it’s longer to write and doesn’t bring anything in terms of “undersatnding” what the parameter does) added should be enough.
To add here, it might be useful to enable checking e.g. the last 5 backups. “-2” is not that useful if it checks only the 2nd latest backup, but it is handy if checks the last two backups.
This is for users with medium levels of paranoia (well, aren’t backups for paranoids in general?)
A more elegant way is to run the following:
for /f “skip=2 tokens=4” %%i in (‘duplicacy list -storage local’) do set LAST_REVISION=%%i
Sorry it hasn’t been implemented. I plan to do it after the memory optimization.
I realize that I’m late to the parameter party here, but please allow me to make two points:
I’ve been thinking a better alternative might be to base the parameter on a fixed time-scale - similar to the -keep parameter, which deals in days. So -last on its own would mean the very last revision, and -last 7 would mean the last 7 days’ worth of snapshots.
Because, as you pointed out, there may be a very different time span covering say, 3 snapshots - depending how long your PC has been switched off. (I do backups every 2 hours.) You have to work out how many snapshots (roughly) you might want to check/copy, based on your job schedule.
Whereas a time-based parameter might yield a different number of snapshots, you know it’s a fixed period of time.
This sounds like an interesting alternative!
I’m wondering how this works in the case where we check and also backup extremely rarely?
My own example, using the same storage GDrive
With your new suggestion, I could do the check like duplicacy check -all -last 20 -tabular and it would only check the validity of the last 20 days worth of backups (maybe i should use 21, since they run at different hours so i might miss some backups). That’s pretty nifty!
Would this work properly with -tabular though? Will tabular only show me the last 20 days, or does it still need to check all the backups? (does it even make sense to run tabular like this?)
On another train of thought: this could also work with copy in the same way. Does it make sense to have it there?
No, I don’t think it would, since at the moment -tabular requires/implies -all - some of those columns, like unique and new, need to know about all the revisions in the storage.
I dunno if it’s worth allowing a subset of snapshots to be checked in this way. Perhaps it’s safer, and not all that more resource intensive, to simply check -all snapshots and chunks. After all, Duplicacy has to ListAllFiles() on the storage anyway.
Though I guess you could use -last n to do it slightly differently - work out the differential of chunks created with n days and just check the existence of those chunks one-by-one, though it’s a less-safe form of check.
Also, I don’t know how check is implemented, but strictly speaking, the second half of the process which does the stats/tabular, shouldn’t necessarily require a physical check for all chunks beforehand. Maybe in the existing implementation the stats are built from the list of chunks it has in memory after checking those chunks exist, but the same information could be built from iterating over all the revision metadata without doing that check. i.e. you could separate out the stats and check operations.
Anyway, I’d propose that -last n - in the case of check, or copy (which I’m most eager to see such a flag) - would always do the last revision plus any snapshots created within n days. Then you wouldn’t have to specify an extra day (21) just in case? If you accidentally skipped jobs, or your PC has been off for a good while, -last n would always include 1 revision minimum, just as -last on its own would.
Posting to add my support for a -r latest or -r last option.
I just setup a copy storage where I’d like to run a more aggressive prune.
I use the Web-UI so calculating latest and running a CLI copy isn’t ideal.
EDIT: As a workaround I’ve set a variable LATEST_REVISION which I can reference from in the CLI. Is there a way to pass that variable to the WebUI which I could use as an option, e.g.
Also just realised I need this desperately! The workaround seems impossible to use on duplicacy-web
Bumping this request for a -latest or -last parameter that I can use with copy in the web app.
My use case:
I back up locally to a large drive (where I’d like to keep as many old versions as can fit) then do a copy to a smaller off-site drive which will only be necessary to recover from catastrophe.
Copy copies everything so at the moment I’m limited by the size of the smaller drive.
-latest would let me prune the smaller drive more aggressively.
