Discussions specific to the VMware vSphere hypervisor
Post Reply
Dude
Influencer
Posts: 15
Liked: never
Joined: Mar 27, 2011 11:57 pm
Contact:

backup to disk, what's your datastore size? over 2 TB?

Post by Dude » Jul 01, 2014 4:34 am

Since Veeam does not de-duplicate across the entire backup repository but only across a backup job one needs to include many VMs (at least those who have the same OS version) into the same backup job if one wants high dedup ratios. Many VMs per backup job in turn means that target datastores have to be fairly large.

What's your datastore size? Do you use datastores which are larger than 2 TB?

It seems like the larger the datastore the higher the probability that either something will go wrong with it and that when something does go wrong with it then a large portion of the backups will be affected. Of course there's more than one backup location, but still, this is about the primary repository.

Thoughts?

Vitaliy S.
Product Manager
Posts: 23001
Liked: 1557 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: backup to disk, what's your datastore size? over 2 TB?

Post by Vitaliy S. » Jul 01, 2014 10:04 am

As far as I remember many people are using iSCSI initiated NTFS volumes to store their backups and the size of these volumes is usually above 2 TB.

Gostev
SVP, Product Management
Posts: 24804
Liked: 3566 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: backup to disk, what's your datastore size? over 2 TB?

Post by Gostev » Jul 01, 2014 11:22 am

Just in case you are thinking of backing up into VMDK attached to backup repository VM, remember that backing up into VMFS is considered a bad practice. You are basically locking the keys in the car by doing that.

Dude
Influencer
Posts: 15
Liked: never
Joined: Mar 27, 2011 11:57 pm
Contact:

Re: backup to disk, what's your datastore size? over 2 TB?

Post by Dude » Jul 01, 2014 5:55 pm

I can see how this is the case if the VMDK is part of the vSphere environment that's being backed up, but if the repository is being accessed from a stand-alone vSphere environment on a separate storage array then is this really the "locking the keys in the car" case? Sure, a functioning vSphere environment is required to restore but the benefit of having the backups in a repository VM and being able to move that around easily seems fairly significant?

Gostev
SVP, Product Management
Posts: 24804
Liked: 3566 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: backup to disk, what's your datastore size? over 2 TB?

Post by Gostev » Jul 01, 2014 6:25 pm 4 people like this post

Dude wrote:but if the repository is being accessed from a stand-alone vSphere environment on a separate storage array then is this really the "locking the keys in the car" case?
No, this approach is rather about adding much unneeded complexity and costs (due to having to maintain separate environment) and reducing reliability (due to more moving pieces that may contain bugs) for no good reason. For example, imagine a hypothetical scenario when vSphere update introduces silent VMFS corruption bug. By the time you notice data corruption in the production vSphere environment, you are likely to have your backup data corrupted in that separate environment as well.

The rule of thumb is that for recoveries, data protection solution should not in any way rely on the system that it is designed to protect. This is because an issue that caused the disaster is somewhat likely to make the recovery impossible, or at least significantly complicate it.

As to the perceived benefits of your planned approach, they are not so great comparing to what you will achieve without introducing VMFS into the picture.

For example, you can even more easily attach the NTFS LUN holding your backups to another server, or even your laptop (should the need arise), and get access to those backup files. I know one customer who did exactly that, which allowed him to spin up domain controller and Exchange on VMware Workstation on his laptop, and run them for a few days while troubleshooting issues with the production cluster (where VMs just would not start due to vSphere bug). True story! Same issue in your scenario means a few days of downtime.

And if you were talking about moving the repository to another physical storage, then again - extra vSphere layer only complicates things. Because with raw LUN, all it takes is just copying backup files with Windows Explorer. This works so much faster, because there is no VMFS in the picture. And does not depend on Storage VMotion, if this is what you are thinking of using for "moving that around easily".

Simplicity always wins complexity in every way.

Dude
Influencer
Posts: 15
Liked: never
Joined: Mar 27, 2011 11:57 pm
Contact:

Re: backup to disk, what's your datastore size? over 2 TB?

Post by Dude » Jul 05, 2014 4:57 pm

Thanks for the detailed write-up Gostev, you make some really good points. I'll reconsider our current approach.

Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests