This is difference in approaches. I haven’t used restic enough to know, but if that’s the case, specifying all the credentials on the command line all the time seems neither better nor worse than configuring storage once and then simply running commands on a named storage. I prefer the latter, but I can see how for simple use cases the former can be preferred. Still, we are talking about the difference in typing one long command vs two short commands. I don’t think this merits long discussion. People tend to like what they first saw and what they got used to, it’s fine.
Reading the discussion, it appears you were unable to add it because of the UX bug, where the button was not visible on a low resolution display. See, you found a bug, thank you!
1 Like
You only have to supply them once when first initializing.
I’m referring to restoring files if you have to do it from a new PC or hardrive if your system crashes.
As long as you’ve safely backed up your backup password, you can restore files from a new PC without having to worry about anything else or trying to re-initialize the remote storage/backup.
I understand all what I read but my only one preocupation now is “How can I declare my existing storage on my new PC ?” Thank to the one that will offer me the solution 
This cannot be the case: Besides backup password you still need to provide storage access credentials. It’s exactly the same for every single backup tool because it’s common sense: you can’t restore data unless you know where from.
Solution. Finally, decreasing the Chrome zoom to 67%, the ADD button appears (and not the + button !!!) and … Miracle… it works. First restore working right now:-)
Here is an example:
I have a remote sftp server that I connect to from my Linux desktop. You can use the domain name or public IP address of the sftp server. I use standard ssh key to connect to this sftp server with no passphrase. Just an ssh key that I put on there via ssh-copy-id.
So now I decide I’m go to backup my photos to this server.
- I decide to create a directory on the sftp server as follows
mkdir /media/photobackup
So now I’m ready to initialize and start backing up.
- On my Linux desktop I run the following
$ restic -r sftp:upssnowm@192.168.1.45:/media/photobackup init
Since I can already connect to this sftp server, the only thing I will get prompted for is a passphrase for the encrypted backup. This passphrase has nothing to do with SSH/SFTP since I can already connect to this server via my ssh keys.
- To backup I run the following:
$ restic -r sftp:upssnowm@192.168.1.45:/media/photobackup backup /home/upssnowman/Pictures.
Here is the good part. My PC crashes and dies…OH NO!!!
I get a new PC and I’m ready to restore my photos.
All I need is my ssh key and to remember what password I used and I’m all set to go.
On my new PC I do the following:
1). Restore my ssh key to /home/upssnowman/.ssh and make sure I can reconnect via ssh to the remote sftp server.
- Simply restore my files to the new PC
$ restic -r sftp:upssnowm@192.168.1.45:/media/photobackup restore latest --target /tmp/Pictures
I just need to supply my password and I’m done.
No fuss, no muss, no reinitializing
This is what happens with Duplicacy if I try to restore on a new PC
Cypher authentication failed is a symptom of a wrong password, or if it relates to sftp — supported key exchange protocols
I see what you mean now.
Yes, duplicacy cannot restore into a void, it always needs to have a local “repository” initialized, albeit in the /tmp/ if needed. It is a conscientious design choice, along with the decision to keep all other metadata (such as exclusion list for example) on the client. File paths in the backup are also tracked from the root of that established “repository”. (What restic calls repository is different than what duplicacy means by it, duplicacy is more aking git in this regard).
There is a third approach, where everything pertinent to the backup is stored at the target — Kopia took that approach. have a look at it too — maybe you’ll like that approach better.
Each design has its pros and cons, and optimizes some usecases more than the others.
I personally don’t mind making another init call in situations that will virtually never occur (total loss of the machine is a rare event) but having the initialized repository helps optimize other, more frequently anticipated usecases.
And lastly, see how you needed to save/restore your ssh keys for restic to work? You can always save the .duplicacy folder to the same place you save your .ssh folder, and restore them together to a new machine. Then you just go duplicacy restore and it “just works”, no need to re-initialize storage. Then it becomes more efficient than restic — you don’t even need to specify path to the storage…
But these things are rather insignificant. Reliability and resilience to corruption what matters in a backup tool, not how many commands are needed to set it up.
1 Like
This error message indicates that the storage password is wrong. If the storage has already been added to the storage page, remove it, add a new one using the same name, and make sure that the storage password is correct.
I may actually end up keeping Duplicacy now, LOL I totally deleted by sftp storage and re-did it from the beginning. Now I’m able to restore to a “new” computer. Not sure what initially happened but it seems to be working now. Thanks to all that responded.
1 Like