Comprehensive data protection for all workloads
Post Reply
TitaniumCoder477
Veteran
Posts: 316
Liked: 48 times
Joined: Apr 07, 2015 1:53 pm
Full Name: James Wilmoth
Location: Kannapolis, North Carolina, USA
Contact:

Enabling encryption on copy job requires full backup

Post by TitaniumCoder477 »

Our client uses a copy job to sync production backups from the datacenter to HQ. The WAN link is about 100Mbps, and the full backup size is about 5TB. So ETA of a full backup would be about 4 1/2 days (https://www.wolframalpha.com/input?i=tr ... at+100Mbps). The target repo is ReFS 64k. I have enabled encryption on the copy job, and I was advised this would not take affect until the next Active Full backup.
  1. Why does Veeam require an Active Full backup to enable encryption on the copy job?
  2. If Veeam needs a full backup before it can start encryption, why can't it synthesize this from all the non-encrypted points already on the target repo?
  3. GFS is already enabled, so will encryption start the next time a GFS point is created? Or, do I literally have to right-click > Active Full which will take a LONG time to go over the pipe?
  4. Will any of the maintenance options help avoid sending literally every block over the pipe again? For example, if I configured "Defragment and compact full backup file" for the next backup?
Mildur
Product Manager
Posts: 9848
Liked: 2607 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: Enabling encryption on copy job requires full backup

Post by Mildur »

Hi James
Why does Veeam require an Active Full backup to enable encryption on the copy job?
We start an encryption with a new set of source blocks. Mixing unencrypted and encrypted blocks in a single backup file is not possible.
If Veeam needs a full backup before it can start encryption, why can't it synthesize this from all the non-encrypted points already on the target repo?
Encryption happens on the source repository before the data gets transferred. Synthetic Fulls are done by the target side where the data is stored.
The source repository cannot synthesize full backups.
So an active full is required to let the source repository encrypt the entire full backup before transferring over the network to the target repository.
GFS is already enabled, so will encryption start the next time a GFS point is created? Or, do I literally have to right-click > Active Full which will take a LONG time to go over the pipe?
For backup copy jobs, you have to start a manual active full backup.
Only if you use periodic backup jobs with the active full option enabled, an active full backup will started automatically.

Will any of the maintenance options help avoid sending literally every block over the pipe again? For example, if I configured "Defragment and compact full backup file" for the next backup?
No, an active full is still required. I suggest to use backup copy seeding. You can create a new backup copy job with encryption and leverage seeding instead of using network upload over the internet.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Thank you
Fabian
Product Management Analyst @ Veeam Software
TitaniumCoder477
Veteran
Posts: 316
Liked: 48 times
Joined: Apr 07, 2015 1:53 pm
Full Name: James Wilmoth
Location: Kannapolis, North Carolina, USA
Contact:

Re: Enabling encryption on copy job requires full backup

Post by TitaniumCoder477 »

Hey Fabian, thanks for the clear and concise reply! It doesn't require an answer or clarification, but I am still puzzled why encryption would only happen on source side. First, if BNR was configured to encrypt in transit using network encryption, then it would seem logical that sending encrypted blocks would be unnecessary. Second, even if BNR is not configured to encrypt in transit using network encryption, as long as the repository is compatible (i.e. Linux or Windows repo that allows for Veeam's data movers/gateway agents etc) to perform on-disk transform processes, why should encryption at the target side NOT be possible? Seems like it should be an option, or even a "smart" choice that Veeam does based on type of repo, compatibility, etc. That said, this is sounding like just lack of capability, which means I should probably count target side encryption as a feature request?

Thank you for reminding me of the seeding. That might work, as these two sites are relatively close and the client has mentioned willingness to transport a USB drive between them in the past. It would just be SOOOOoooo much easier of Veeam could tell the components on the target repo to do the encryption on disk! (or even synthesize a full from existing blocks, encrypting them as they are injected into the new full)
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Semrush [Bot] and 73 guests