Why add a revision when it is identical with the previous one?

backup

#1

I noticed that the revision number increases every single time the backup runs, even when no changes are made whatsoever

Backup for **** at revision 30 completed
Files: 1960 total, 49,037M bytes; 0 new, 0 bytes
File chunks: 9971 total, 49,041M bytes; 0 new, 0 bytes, 0 bytes uploaded
Metadata chunks: 3 total, 1,222K bytes; 0 new, 0 bytes, 0 bytes uploaded
All chunks: 9974 total, 49,043M bytes; 0 new, 0 bytes, 0 bytes uploaded
Total running time: 00:00:03
Backup for **** at revision 31 completed
Files: 1960 total, 49,037M bytes; 0 new, 0 bytes
File chunks: 9971 total, 49,041M bytes; 0 new, 0 bytes, 0 bytes uploaded
Metadata chunks: 3 total, 1,222K bytes; 0 new, 0 bytes, 0 bytes uploaded
All chunks: 9974 total, 49,043M bytes; 0 new, 0 bytes, 0 bytes uploaded
Total running time: 00:00:04

and so on…

Is this intentional and if so, what’s the advantage as compared with increasing the revision number only when the new revision is from the previous one?


#2

Because this is the most straightforward implementation, i.e., no extra logic to decide if the revision is the same as the latest one. I would argue that this makes sense in some cases, like if a different backup tag is specified, or to stick to a strict schedule of, say, one revision per day.


#3

My concern is just that if you have frequent (say: hourly) backups, it wont take long until you have revision numbers that are not easily readable to the human eye and which invite typing errors when you have to type them.

And the GUI restore dropdown listing all revisions becomes extremely long (and eventually also wide, forcing the user to re-adjust the with of the modal). Granted, the GUI mitigates the problem somewhat by including the time and date of the revision (as well as tags, I believe?).


#4

Came here to ask the same :slight_smile: I use Arq backup on osx that I plan to move away from, it only creates a new revision if anything changes.

Perhaps a new method we can use to check if anything has changed, then we can script it to upload or flag of sorts to allows for that behaviour?

In fairness I could probably get away with backing up once a day would prefer hourly, plus computer is put to sleep half of the day.

E.g. assuming I backup once an hour;

if I was working on a file throughout the day, hourly backup manages to catch 4 changes.

Next day I delete it and want to recover it, I’d probably have to go through each snapshot not knowing which snapshot the file changed in? Unless theres a easy way to figure that out now?

Maybe keep the revisions but have a flag to show only revisions with changes?

Another question; can Duplicacy prevent computer sleep while backing up?

(edited post)


#5

The history command can tell you how a file changes over time/revisions:

duplicacy history -r 10-100 relative/path/to/file

#6

@gchen thanks I had spotted that :slight_smile: just not as friendly.

Think I might just script it with find . -mtime -1 or similar to only backup if anything has changed.


#7

If a new revision is only created if something changed and you have a repository with very static data, there would be a chance you reach the point where you prune the snapshots and then your backup will miss all the unchanged files until you run another backup. Sure chances are small you’ll need the backup in exactly this timeframe but if it happens you’ll have a very bad day.

@iluke the way Duplicacy works now, the file is included in each of your revisions, so you can restore from the latest one. You’re absolutely fine running a backup every hour and if you don’t need to keep all these revisions for a long time, just prune regularly.


#8

@Nelvin good point :slight_smile: hourly should be fine, thanks


#9

@Nelvin this is a solid reason for creating a new revision when there is no change.