Passphrase cannot be changed for an existing backup

Hello,
Your app is great when … everything works fine.
I changed my passphrase which was old and weak.
I can no longer save.
How to do with an order !? a backup:
1 / keeping the remote backup
2 / by overwriting the remote backup (I tried and it took a long time to succeed, in another case). What interests me is to get there as quickly as possible
Regards

You mean the encryption passphrase, right? If you mean the passphrase for accessing remote storage - that definitely can be changed.

I don’t believe the encryption passphrase can be changed. It may be more straight forward to delete the all the back end data and the local database for the job, change the encryption password, and then start backing up fresh. This will take a long time for the initial backup and you’ll lose access to your backup history.

If you want to retain your backup history, you can turn off automatic backups for the job and just stop using it for new backups. Use it only for restores. Set up a second, new backup job with the encryption key you want and target a new remote storage location. (Remember not to have two backup jobs using the exact same back end storage location.) This, too, will take a long time for the initial backup depending on how much data you are protecting. Plus you will use roughly twice the storage on the back end keeping both backup sets.

It MAY be possible (I haven’t tried or researched) to change the encryption passphrase if you manually decrypt and then re-encrypt all the back end files. Duplicati provides a command line tool for (SharpAESCrypt.exe) that could make this possible. If your back end is AWS S3 (or another provider that can also provide virtual machines), you could set up a temporary VM in the same region to do all the processing more quickly. I wonder if anyone has tested this approach.

Edit: Never mind, that won’t work because the file hashes will all be changed on the back end and won’t match the local database.

You can, but it will download all data, decrypt and reencrypt your data, and upload it again.
I did it succesfully while moving away from AES and towards GPG encryption. It should also work when just changing the password.

Use at own risk…

@Wim_Jansen - isn’t that talking about just changing encryption on the database itself? Or does it really change encryption on all back-end files too?

Never mind - I see the python script. Interesting! Was just a bit confusing because it uses “database” in the title when it really is about changing encryption on the back-end.

correct - I made the initial version of the script, but not the wiki :slight_smile:

Hello,
Thank you for taking the time to respond.
Yes it is the paraphrase, I have the message

You have attempted to change a passphrase to an existing backup, which is not supported. Please configure a new clean backup if you want to change the passphrase.

I was hoping that an advanced option existed, in the configuration.
Can I make this suggestion (or is it too difficult because at the heart of the program?)

If there are no other solutions, I will delete the remote backup folder. I am aware that deleting / transferring a new backup (10go) will be long but I do not know enough to do something else.
I have already tried but even if there is no more remote backup, it still fails.
At this point should I generate another paraphrase?

Regards

Anyone can make any suggestion in the Features category, but there’s a long waiting list, in GitHub too. Possibly you will already find such a suggestion, in which case you could read that discussion, add, etc.

“Heart of the program”, though, might be why such complete reworking is currently in a standalone tool:

Duplicati.CommandLine.RecoveryTool.exe (where the main goal of a total rewrite is doing recompress)

If --reencrypt is supplied, all files are re-encrypted using the same passphrase.

I wonder if “same passphrase” is to avoid having a backup on different passphrase during conversion? Duplicati has no way to say “these files take this passphrase, and these other files take this other one”.

Some encryption schemes have the user passphrase encrypt the encryption key used on the data, and changing the user-supplied passphrase is a simple matter of re-encrypting the data encryption key, so there is no need to download, upload, or otherwise replace a lot. I don’t know if it fits Duplicati’s design.

For protection, if the local drive is lost, you’d need some remote info, such as encrypted encryption key, and there’s not currently a file at the remote with configuration info of backup. That’s another request…

Back to the immediate wish to get back soon, were you in the web UI, changing the password, and got:

image

which button did you use? If you changed the password despite warning, can you just change it back? You can also look at your destination to see if any new files were made. If not, everything is still intact.

image

is what I get if I tell it to break my backup then try a backup. Changing password back fixed everything. Possibly the message could be clarified to offer the way back. Does just changing back resolve yours?

Hi,
Thank you for your contributions. I tried but it didn’t work :frowning:
I don’t think there are any solutions apart from destroying the backup configuration and remote backups. That’s what the message says
Regards

Looking at backup file timestamps is first way to see if anything actually changed on destination.
Trying direct restore is another way to see if it’s intact. You enter the passphrase directly to it, so passphrase issues (or complaints) due to existing configuration database can’t possibly enter in.

Message is correct if you really want to change the password (without making some special effort).

However if “there” is backing up with the old password, that hasn’t been fully explored. Your choice.

HI,
I have deleted the remote files and recreated a new backup.
It was long and difficult. I would remember that you can’t change the passphrase.
The easiest if this passphrase is known, it would be to change the remote password (and therefore authId)
Regards