-
- Lurker
- Posts: 2
- Liked: never
- Joined: Jan 22, 2025 2:52 pm
- Full Name: Graeme
- Contact:
Best practice for changing backup encryption passwords
Having enabled backup encryption with a password stored in veeam encryption credentials (and assigned to various jobs) we need to start rotating this password periodically. Should we cycle this by creating a new credential and assigning it to jobs instead or can we just edit the password on the existing saved credential?
I assume Veeam uses the stored credential for restores so if we edit the stored credential would that cause issues for restores from prior to the change - or for other operations like when consolodating encrypted backups?
the below help page just says "if you change the password..." but I don't know if that means literally change the existing stored credential.
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
I assume Veeam uses the stored credential for restores so if we edit the stored credential would that cause issues for restores from prior to the change - or for other operations like when consolodating encrypted backups?
the below help page just says "if you change the password..." but I don't know if that means literally change the existing stored credential.
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
-
- Veeam Software
- Posts: 2931
- Liked: 674 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Best practice for changing backup encryption passwords
Hi grame321, welcome to the forums
Either way works, you can edit the encryption password and enter a new password to update it, or create a new encryption key. Please keep in mind the considerations here in the relevant User Guide page.
Hint: You can use Powershell to automate the rotation of encryption keys; Set-VBREncryptionKey accepts a SecureString object so you can likely avoid having plain-text for such a script
Either way works, you can edit the encryption password and enter a new password to update it, or create a new encryption key. Please keep in mind the considerations here in the relevant User Guide page.
Hint: You can use Powershell to automate the rotation of encryption keys; Set-VBREncryptionKey accepts a SecureString object so you can likely avoid having plain-text for such a script
David Domask | Product Management: Principal Analyst
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Jan 22, 2025 2:52 pm
- Full Name: Graeme
- Contact:
Re: Best practice for changing backup encryption passwords
Thanks for the prompt response, I do plan to use powershell to automate the changes.
Does changing the password affect how we access (restore) backups from prior to the change of password? Will we need to provide the previous password?
Does changing the password affect how we access (restore) backups from prior to the change of password? Will we need to provide the previous password?
-
- Veeam Software
- Posts: 2931
- Liked: 674 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Best practice for changing backup encryption passwords
You're quite welcome, happy to help.
> Does changing the password affect how we access (restore) backups from prior to the change of password? Will we need to provide the previous password?
No, just importing encrypted backups will be affected in specific situations; if the encryption key gets removed from Veeam/lost, you'll need the most recent password to decrypt the backup chain. Veeam will prevent users from removing encryption keys still in use though so usually this scenario is only if you had a loss of the VBR server itself and did not have a Configuration Backup to restore from or if you're importing encrypted backups into a fresh VBR installation.
If you use Enterprise Manager, consider using Lost Password Protection to ensure you can import encrypted backups regardless of what happens to the backup server / stored encryption keys.
> Does changing the password affect how we access (restore) backups from prior to the change of password? Will we need to provide the previous password?
No, just importing encrypted backups will be affected in specific situations; if the encryption key gets removed from Veeam/lost, you'll need the most recent password to decrypt the backup chain. Veeam will prevent users from removing encryption keys still in use though so usually this scenario is only if you had a loss of the VBR server itself and did not have a Configuration Backup to restore from or if you're importing encrypted backups into a fresh VBR installation.
If you use Enterprise Manager, consider using Lost Password Protection to ensure you can import encrypted backups regardless of what happens to the backup server / stored encryption keys.
David Domask | Product Management: Principal Analyst
-
- Influencer
- Posts: 23
- Liked: 9 times
- Joined: Oct 09, 2024 6:17 pm
- Contact:
Re: Best practice for changing backup encryption passwords
IMO a new credential entry should always be created with a fresh description. I try to follow a process like this:
1. Create the password in your secret/credential system. Backup and do a restore test of that secret/credential system itself (don't you love the catch-22s in this industry?).
2. Create a new credential with a description/note of "Encryption key commissioned and put into service. YYYY-MM-DD. Case/change reference ######.". Use a name that makes clear the vintage of the key (YYYY-MM-DD commission date).
3. Update jobs using the "old" encryption key entry to use the new credential entry. Tip: you can use the delete credential button in the credential manager to give you a listing of where the key is being used.
4. Update the "old" encryption key entry/credential description and name to clearly note it's been superseded and the date range it was in service.
5. Update the "old" encryption key/password in your secret credential with the same - knowing what dates it was in service.
All of these steps allow for in the event that the VBR system explodes you know exactly which keys are the most important to get back into service vs which are for old backups that you're (likely) not needing right away in a rebuild scenario, but still allow you to easily decrypt old chains.
1. Create the password in your secret/credential system. Backup and do a restore test of that secret/credential system itself (don't you love the catch-22s in this industry?).
2. Create a new credential with a description/note of "Encryption key commissioned and put into service. YYYY-MM-DD. Case/change reference ######.". Use a name that makes clear the vintage of the key (YYYY-MM-DD commission date).
3. Update jobs using the "old" encryption key entry to use the new credential entry. Tip: you can use the delete credential button in the credential manager to give you a listing of where the key is being used.
4. Update the "old" encryption key entry/credential description and name to clearly note it's been superseded and the date range it was in service.
5. Update the "old" encryption key/password in your secret credential with the same - knowing what dates it was in service.
All of these steps allow for in the event that the VBR system explodes you know exactly which keys are the most important to get back into service vs which are for old backups that you're (likely) not needing right away in a rebuild scenario, but still allow you to easily decrypt old chains.
Who is online
Users browsing this forum: Google [Bot], Semrush [Bot] and 47 guests