I wanted to ask for your opinion regarding security.
Do you think it makes more sense to use an immutable repository as the primary backup target, rather than as a secondary one?
Let me explain: if the first copy is written to a traditional repository and only the second copy goes to an immutable one, there’s a risk of transferring data already compromised by ransomware to the immutable repository.
Would you consider this a logical concern?
-
- Expert
- Posts: 124
- Liked: 2 times
- Joined: Feb 21, 2020 11:30 am
- Full Name: massimiliano porliod
- Contact:
-
- Veeam Software
- Posts: 2837
- Liked: 647 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Evaluating the Strategy: Immutable Repository as Primary vs Secondary in Veeam
Hi mporliod,
Both sides immutable is really the best answer if possible -- your logic isn't wrong at first blush, but if you're meaning that you worry about transferring a backup that has been encrypted by ransomware, almost certainly in most cases the backup copy would fail. For the actual GuestOS data, that is not a concern once it's in the backup except for bitrot/corruption on the backup file.
A lot of attacks on backups are meant to either delete entirely or encrypt the backups, the goal being to render them useless while holding production machines hostage. Encryption for the backups typically is a quick encryption of first few MB of the file (I think 15 MB is max) to render the backup file useless, which will prevent Veeam operations from working with these files. Neither the delete nor the encryption take very long, so it's best to have immutable backups wherever possible to mitigate the risk.
Ideally, having immutability on both parts is best -- Backup Copies need valid primary backups to work with, so if only the secondary site is immutable then you're at risk until the backup copy completes and you finally have immutable backups of your production.
Both sides immutable is really the best answer if possible -- your logic isn't wrong at first blush, but if you're meaning that you worry about transferring a backup that has been encrypted by ransomware, almost certainly in most cases the backup copy would fail. For the actual GuestOS data, that is not a concern once it's in the backup except for bitrot/corruption on the backup file.
A lot of attacks on backups are meant to either delete entirely or encrypt the backups, the goal being to render them useless while holding production machines hostage. Encryption for the backups typically is a quick encryption of first few MB of the file (I think 15 MB is max) to render the backup file useless, which will prevent Veeam operations from working with these files. Neither the delete nor the encryption take very long, so it's best to have immutable backups wherever possible to mitigate the risk.
Ideally, having immutability on both parts is best -- Backup Copies need valid primary backups to work with, so if only the secondary site is immutable then you're at risk until the backup copy completes and you finally have immutable backups of your production.
David Domask | Product Management: Principal Analyst
-
- Veeam Software
- Posts: 748
- Liked: 167 times
- Joined: Jan 22, 2015 2:39 pm
- Full Name: Stefan Renner
- Location: Germany
- Contact:
Re: Evaluating the Strategy: Immutable Repository as Primary vs Secondary in Veeam
David is correct, you should enable immutability on both, and I would even prefer primary over secondary.
Attacker will attack your backups first and if the compromise your primary backup you will only be able to recover from secondary which mean your RPO will be different and depending on your data this might already be a big issue as you would loose most recent data.
Attacker will attack your backups first and if the compromise your primary backup you will only be able to recover from secondary which mean your RPO will be different and depending on your data this might already be a big issue as you would loose most recent data.
Stefan Renner
Veeam PMA
Veeam PMA
Who is online
Users browsing this forum: Amazon [Bot], Google [Bot] and 44 guests