Duplicacy list doesn't show the rights snapshots

Bug
#1

Hi everyone !
Please describe what you are doing to trigger the bug:
I’m trying to backup multiples clients on the same repository. Every client backup with a different tag.

client1#duplicacy init -repository /data/test-duplicacy -e common sftp://user@ip//backups/common
client2#duplicacy init -repository /data/test-duplicacy -e common sftp://user@ip//backups/common
client3#duplicacy init -repository /data/test-duplicacy -e common sftp://user@ip//backups/common

4 times on client1 :
duplicacy backup -t client1 -stats

4 times on client2 :
duplicacy backup -t client2 -stats

4 times on client3 :
duplicacy backup -t client3 -stats

Please describe what you expect to happen (but doesn’t):
I was expecting the duplicacy -list -t client1 to show me every snapshots made by the client 1.

Please describe what actually happens (the wrong behaviour):
Instead, it displayed 3 snapshots out of 4
On client 1 : duplicacy list -t client1
Repository set to /data/test-duplicacy
Storage set to sftp://user@ip//backups/common
Snapshot common revision 1 created at 2019-07-31 15:40 client1 -hash
Snapshot common revision 3 created at 2019-07-31 15:42 client1
Snapshot common revision 6 created at 2019-07-31 15:48 client1

On client 1 : duplicacy list
Repository set to /data/test-duplicacy
Storage set to sftp://user@ip//backups/common
Snapshot common revision 1 created at 2019-07-31 15:40 client1 -hash
Snapshot common revision 2 created at 2019-07-31 15:41 client3
Snapshot common revision 3 created at 2019-07-31 15:42 client1
Snapshot common revision 4 created at 2019-07-31 15:43 client3
Snapshot common revision 5 created at 2019-07-31 15:45 client3
Snapshot common revision 6 created at 2019-07-31 15:48 client1
Snapshot common revision 7 created at 2019-07-31 16:39 client2

Maybe a problem with the display function ?

#2

It seems your backup ran 3 times with the client1 tag, 3 times with the client3 tag and once with the client2 tag.

Both runs of the list command above show compatible / correct outputs.

The question then is whether the commands were actually executed 4 times for each client.

A minor naming correction: “…on the same storage”. Repositories are the locations / folders where the source files are on clients.

BTW, you can use in addition to tags (or instead of tags, depending on your needs) different repository names, one for each client. It depends on how you want to organize / name the backups, whether the source files are of different types, etc.

Another clarification about the Duplicacy nomenclature (yes, it is confusing at beginning): Each time the backup is performed, a revision is generated.

Snapshot is associated with the source repository. The snapshot ID in your case is “common”.

#3

Thanks for your reply !

My main problem is, why it doesn’t show me the 4 revisions when I execute the command : duplicacy list -t client1 ?

I don’t know if this use case is handled by Duplicacy but, if it works, I can easily run the command above and grep the last revision available, then restore it.

#4

I think the question is: was the backup actually executed 4 times on each client?

#5

Yes, 4 times on each client, totally sure :smiley:

#6

When you use the same repository id common on different computers, a race condition may occur when backups are running at the same time. For example, when both client1 and client2 see revision 5, they will think they will be working on revision 6, but the one who finishes later will overwrite the earlier one.

That is why using different repository ids on different computers is very important.

2 Likes
Init command details
#7

So what is the correct terminology here?

or

2 Likes
#9

I find the terminology “snapshot id” a bit confusing.

As per wikipedia the word SNAPSHOT is described as

In computer systems, a snapshot is the state of a system at a particular point in time.

So, the word “snapshot id” doesn’t intuitively map to a universally unique ID for a given repository that needs to be true across time as it is defined in docs currently, which is very contrary to the point in time essence of the word ‘snapshot’. Instead, “Repository ID” would/could have been a better term for it - which I don’t see as being used currently for anything.

Am I missing any alternative perspective OR is the decision to hold on to the terminology to avoid confusion for existing users?

#10

Regarding terminology, you might also want to check out this topic: