-
- Novice
- Posts: 7
- Liked: never
- Joined: May 29, 2012 7:59 am
- Full Name: Martin Jubb
- Contact:
Should we make our hard drives smaller?
Morning all,
We have a customer that is currently using a 1Tb RDM for their file server. We're going to storage vMotion it into a vmdk.
My question is, would it be better to take break the information down into smaller hard drives so Veeam doesnt have to backup a 1 x 1Tb drive.
Im thinking of this from 2 points of view:
1. What happens if there is a failure at some point through the backup?
2. What happens if we need to restore the vmdk?
In both cases, if the data is spread over smaller hard drives, we minimise the area of risk and its faster to restore a smaller vmdk than a larger vmdk and impacts fewer users.
What are your thoughts on this?
Thanks
We have a customer that is currently using a 1Tb RDM for their file server. We're going to storage vMotion it into a vmdk.
My question is, would it be better to take break the information down into smaller hard drives so Veeam doesnt have to backup a 1 x 1Tb drive.
Im thinking of this from 2 points of view:
1. What happens if there is a failure at some point through the backup?
2. What happens if we need to restore the vmdk?
In both cases, if the data is spread over smaller hard drives, we minimise the area of risk and its faster to restore a smaller vmdk than a larger vmdk and impacts fewer users.
What are your thoughts on this?
Thanks
-
- VeeaMVP
- Posts: 6166
- Liked: 1971 times
- Joined: Jul 26, 2009 3:39 pm
- Full Name: Luca Dell'Oca
- Location: Varese, Italy
- Contact:
Re: Should we make our hard drives smaller?
Veeam uses CBT to backup only effective data blocks, so if the disk is 1 Tb but its usage is lower, backup will save only used blocks. Also, this is for the first run, un subsequent incremental runs only modified blocks will be saved.
I think you have to design your vSphere infrastructure for production, and then adapt Veeam to backup that infrastructure. Do not design a production environment having backup as primary goal in mind. Veeam can be used in many scenarios without modifying them.
Luca.
I think you have to design your vSphere infrastructure for production, and then adapt Veeam to backup that infrastructure. Do not design a production environment having backup as primary goal in mind. Veeam can be used in many scenarios without modifying them.
Luca.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
-
- Novice
- Posts: 7
- Liked: never
- Joined: May 29, 2012 7:59 am
- Full Name: Martin Jubb
- Contact:
Re: Should we make our hard drives smaller?
Hi Luca,
I agree with most of what you say but i think you should be thinking about data recovery and business continuity when designing a virtual environment. Veeams ability to get you quickly up and running again is one of its main selling points.
Are there are downsides to backing up several smaller vmdk's rather than 1 big vmdk?
I agree with most of what you say but i think you should be thinking about data recovery and business continuity when designing a virtual environment. Veeams ability to get you quickly up and running again is one of its main selling points.
Are there are downsides to backing up several smaller vmdk's rather than 1 big vmdk?
-
- VeeaMVP
- Posts: 6166
- Liked: 1971 times
- Joined: Jul 26, 2009 3:39 pm
- Full Name: Luca Dell'Oca
- Location: Varese, Italy
- Contact:
Re: Should we make our hard drives smaller?
None. I read in another post a user has a VM with 29 vmdk attached to it, and has no issue with Veeam.
There is a limit in the FLR appliance to mount a maximum of 20 vmdk but it can be changed via registry key. Until you reach these values you are fine even withut the hack.
There is a limit in the FLR appliance to mount a maximum of 20 vmdk but it can be changed via registry key. Until you reach these values you are fine even withut the hack.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
-
- Novice
- Posts: 7
- Liked: never
- Joined: May 29, 2012 7:59 am
- Full Name: Martin Jubb
- Contact:
Re: Should we make our hard drives smaller?
Great,
that's what we'll be considering in future designs then.
Thanks.
that's what we'll be considering in future designs then.
Thanks.
-
- Enthusiast
- Posts: 38
- Liked: 2 times
- Joined: Dec 07, 2011 5:21 pm
- Full Name: Serge Adam
- Contact:
Re: Should we make our hard drives smaller?
My largest VM has 4 1.9TB VMDKs in a spanned volume. No problems backing it up
-
- Novice
- Posts: 5
- Liked: never
- Joined: Jul 05, 2012 4:16 pm
- Full Name: Matt Atkins
- Contact:
Re: Should we make our hard drives smaller?
I know that this is more of a VMWare config question but Veeam brought the problem to my attention and the answer changes the way Veeam is used.sergeadam wrote:My largest VM has 4 1.9TB VMDKs in a spanned volume. No problems backing it up
Sergeadam,
Why did you choose to go the multiple 1.9TB VMDK route instead of one big RDM disk? I work for an advertising agency and we deal with very large amounts of data. Initially I did the same with my new file server and created 4 2TB disks and and extended them in Windows to make one big 8TB disk. When I tried to back the VM up with Veeam for the first time, it failed because the VMDKs were over 2TB. After lots of research and discussions, it was suggested to me to use a large RDM instead of multiple VMDKs and then use my backup application to back up the data on the RDM to tape instead of trying to use Veeam.
What say you Veeam experts?
-
- VP, Product Management
- Posts: 27377
- Liked: 2800 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Should we make our hard drives smaller?
Hi Matt, if you do this you will lose an ability to restore the entire image of your file server, which is not the case with 2 TB vRDMs/VMDK disks. Thanks!
-
- Veeam Software
- Posts: 21139
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Should we make our hard drives smaller?
Matt, what was the reason of the failed job? Please note, that the maximum size of a virtual disk should be 2TB - 512 bytes to make snapshots of the disk possible (which is a requirement for an image-based backup). If you could make your disks smaller (1.9TB, for example, as Serge has stated above), you could successfully back up a spanned volume.
-
- Novice
- Posts: 5
- Liked: never
- Joined: Jul 05, 2012 4:16 pm
- Full Name: Matt Atkins
- Contact:
Re: Should we make our hard drives smaller?
I'm backing up the actual data to tape, just like I did/do in my bare metal world. Until I have a branch office up and running with their VMWare environment, I still have an offsite backup storage requirement. I was told by VMWare tech support that because I'm dealing with such a large amount of data, to add a huge RDM to the VM instead of multiple 2TB datastores because of how long it would take for snapshots. That's why I changed it from how I had it.Vitaliy S. wrote:Hi Matt, if you do this you will lose an ability to restore the entire image of your file server, which is not the case with 2 TB vRDMs/VMDK disks. Thanks!
The job did indeed fail because I was unaware of the 2TB-512 bytes limitation. It was my first attempt at a Veeam backup of the file server that brought all of this to my attention and what prompted my call to tech support.foggy wrote:Matt, what was the reason of the failed job? Please note, that the maximum size of a virtual disk should be 2TB - 512 bytes to make snapshots of the disk possible (which is a requirement for an image-based backup). If you could make your disks smaller (1.9TB, for example, as Serge has stated above), you could successfully back up a spanned volume.
Who is online
Users browsing this forum: No registered users and 35 guests