Comprehensive data protection for all workloads
Post Reply
Doug.Butler
Enthusiast
Posts: 30
Liked: 4 times
Joined: Jun 22, 2011 10:41 pm
Full Name: Douglas J. Butler
Contact:

Deduplication and Compression for Backup Copy to VNXe

Post by Doug.Butler »

Aargh! I just typed this post up, took me 20 minutes, and it all disappeared when I clicked "Preview." Oh well here goes again... briefer, this time!

I recently upgraded from B&R V6.5 to V7.0 (7.0.0.690) and added an HP tape library. I want to begin using Backup Copy and Backup Copy to Tape jobs to implement the 3-2-1 rule set / policy. (3 copies, 2 different media, 1 offsite.)

I decided to create an entirely new backup job, and then also add Backup Copy and Backup Copy to Tape to get the required coverage. The first run of the Backup Copy job took way longer than I expected, so I am looking for recommendations on the settings. I believe the biggest issue is that I am deduplicating twice, and I also wonder if there is any point in using Compression for the Backup Copy job, when the job's source is already compressed.

The Source of my Backup Copy job is based on my "Daily Backup" job, which uses local disk (3.5TB volume on a RAID6 internal array) as its repository. The Target repository for the Backup Copy job is a CIFS share on a Capacity pool (12x NL-SAS disks in RAID6) on an EMC VNXe3100 storage system. Both the Veeam server and the VNXe have 1-gigabit LAN connectivity.

The data set that eventually wound up on the CIFS share was about 1.4TB and took over 24 hours to complete. Some VM's got skipped (i.e. the job failed) because it did not complete in the window of time available. Ignoring all overhead factors, I calculate that 1.4TB of raw data transfer should take approx. 4 hours on a gigabit LAN. Obviously something is sub-optimal!

The CIFS share on the VNXe has Deduplication enabled. The Backup Copy job also has Deduplication enabled, and Compression set to "Auto (recommended)" which are the default settings.

Should I disable Deduplication and/or Compression on the Backup Copy job?
dellock6
VeeaMVP
Posts: 6139
Liked: 1931 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy
Contact:

Re: Deduplication and Compression for Backup Copy to VNXe

Post by dellock6 »

Is the deduplication/compression on the VNXe in real time? If so, try to use only the data reduction features of Veeam, if dedup is real-time almost sure your backup times will be improved.

Luca.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software

@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Doug.Butler
Enthusiast
Posts: 30
Liked: 4 times
Joined: Jun 22, 2011 10:41 pm
Full Name: Douglas J. Butler
Contact:

Re: Deduplication and Compression for Backup Copy to VNXe

Post by Doug.Butler »

dellock6 wrote:Is the deduplication/compression on the VNXe in real time? If so, try to use only the data reduction features of Veeam, if dedup is real-time almost sure your backup times will be improved.

Luca.
Thanks for the reply. To be clear, when you say "try to use only the data reduction features of Veeam," does that mean "turn off deduplication and leave compression enabled on the backup copy job"?

Thanks again.
dellock6
VeeaMVP
Posts: 6139
Liked: 1931 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy
Contact:

Re: Deduplication and Compression for Backup Copy to VNXe

Post by dellock6 »

No, I mean enable both deduplication and compression inside Veeam, and disable the same features in the VNXe.

Luca.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software

@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Doug.Butler
Enthusiast
Posts: 30
Liked: 4 times
Joined: Jun 22, 2011 10:41 pm
Full Name: Douglas J. Butler
Contact:

Re: Deduplication and Compression for Backup Copy to VNXe

Post by Doug.Butler » 1 person likes this post

After some further reading, I have learned that on the VNXe3100, the deduplication is file-level, not block-level, and so I no longer think this is the cause of the slow performance. I now think it's the basic fact that I'm backing up to a CIFS share on a NAS rather than to a Windows-based repository.
Post Reply

Who is online

Users browsing this forum: MaartenA, Semrush [Bot] and 88 guests