Yes the system will use the password for encryption you select in your job.

If someone gains access to the NAS unless they have the backup password you used for encryption then they cannot restore files.

I will check on the file level restore unless VBR is saving the password somewhere for this so it won’t prompt you that may be the case.

Couple of good links -

Backup Job Encryption - User Guide for VMware vSphere (veeam.com)

Job Encryption - Veeam Backup & Replication Best Practice Guide

Info about the password not being prompted on file restore - Restoring Data from Encrypted Backups - User Guide for Microsoft Hyper-V (veeam.com)

Thanks for the reply and documentation Chris. Since there is a “manage password option” when setting up encryption, I am assuming the app is managing the passwords for me.

Hi @DT60 to elaborate on some of this, Veeam knows the password to encrypt/decrypt as it’s using it each time it makes a new backup, so it uses it also for each restore request. If you lose your Veeam installation, then you have to re supply the password.

So in this scenario, your data is safe if the files at rest were copied somewhere else and accessed by anything other than the version of Veeam that knows the password, but if they compromised your Veeam instance, then you’ve got problems!

When your Veeam instance is compromized hou have some more problems than the encryption password…

E.g. accounts and passwords for your vSphere cluster and so on...

100%
 

I still believe when your backups are compromised, your attacker has the best possible copy of data to extort you with.

If you’ve processed your applications such as SQL server so it’s transactionally consistent, they now have a guaranteed good copy of your database. Backups are processed for data efficiency such as compression & dedupe so they’ve got a smaller file which is easier/faster to egress from your environment too. Just a couple of thoughts

It seems to me that in most situations, if the bad actor has reached your backups, they’re generally not trying to access the data inside, but instead either encrypt or delete those backups.  Now granted, the newer style of ransomware is not to exfiltrate data so that they can hold it ransom with a threat of releasing it to the public, but that’s a bit more involved.  And again, I would want my backups encrypted if that was going to be the case, and of course, if they got your backups, they probably have your production data as well.  

Exactly, same thing for Agent file restore if executed from same machine that did backup.

Mmh the scenario is changing, lastest cases show that attackers are trying to access backups to enumerate passwords or critical files, maybe saved on permission protected area but accessible via file recover, to do an easy-way privilege escalation or direct access to systems via valid credentials.

But what you said is not wrong :)