Restore latest version of a file

Feature
,
#1

Do I understand correctly that there is currently no simple way of restoring the latest revision (or a file from that revision? If so, I would like to suggest this feature. For example smething like this should work:

duplicacy restore -r latest the/file/to/be/restored

Currently, you painfully have to use something like

duplicacy list -id <repo.id>

or

duplicacy list -id <repo.id> -r 100-250

(if you know roughly how many revisions there are) to identify the latest revision and then use

duplicacy restore -r 180 the/file/to/be/restored

Suggestions for the option name

-last

-latest

-r latest (as in revision "latest")

-r -1 (as in revision "-1")
4 Likes
How to check only the latest revision?
Roadmap for the CLI
#2

IMO, Duplicacy desperately needs this option for an important reason… even if you could script it, a script wouldn’t always be as efficient.

I’m thinking about a use case of the copy command where, if I want to copy the latest revision of several repositories, I have to iterate over them in a script.

This can be a big problem, because the copy command will try to list all chunks before copying anything across. With some storages (particular Vertical Backup storages with lots of chunks and several VMs), listing chunks takes a loooong time. So a script that does one VM repo at a time is incredibly inefficient.

With a -r latest, -latest, or even -r -1 option, I could do a single `copy’ command and have it do all the repositories, but it would only have to list the chunks once.

(You may ask why I don’t copy with the default option; all repositories and all revisions - quite simply, bandwidth constraints. These VMs are backed up three times a day and I only copy to off-site storage once a week. IF there was a way to copy only a -tag, this option for me would be just as valuable, but currently the copy command doesn’t support tags or a latest option.)

2 Likes
#3

Yes, good to see this confirmed by an expert. I thought it was such an evident feature that I was unsure whether I missed something.

@gchen, wouldn’t it be rather easy to implement this?

I think the -1 could be somewhat confusing in a context where the minus by default signifies an option rather than an option value.

#4

We did have exactly same conversation over a year ago, and gchen did not seem to object – but I guess it is still low in the priority list

3 Likes
#5

OMG! I vaguely remembered having discussed this before and even searched the forum. No idea why I didn’t find the other topic. Oh, probably because it was about the check command and now it’s about restore. :slight_smile:

I someone ever has time to spare, I think a table showing all options shared by more than one command might be handy.

@gchen could you say something about whether the -r latest option is on the roadmap?

1 Like
#6

I prefer -1 over -latest because you can then have -2, -3, etc. It looks like -r -1 won’t cause any problem to the command line parsing library Duplicacy is using.

This would be a small change, but I also want to rework the current code so that all commands will take the same arguments (revisions and tags) and use the same code to get the list of revisions to work with. I plan to do this after the memory optimization task.

7 Likes
Duplicacy is causing HUGE load on my server
#7

@gchen in this topic i see your following opinion:

Whereas in the CLI Roadmap

you mention using -r latest instead.

Which is the desired option?

If it matters, -1 is better than -latest imo

#8

IMO, the option flag - since we’re talking about revisions - should still be signified by -r…

The value after that is usually positive, but to support the new concept of the latest revision, it could maybe use negative values. So: -r -1 for latest, -r -7 for the last seven etc… Then, you could theoretically have latest (no preceding dash) as an alias for -1. So: -r latest could do the same.

That’s 2p anyway.

4 Likes
#9

Is this still being considered? If not, I’d like to propose it again.

1 Like