Comprehensive data protection for all workloads
Gostev
SVP, Product Management
Posts: 24017
Liked: 3254 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: +2TB sizes (again)

Post by Gostev » Apr 29, 2011 5:15 pm

This is bad for dedupe and ultimately means excessive storage loss. Not just those multiple unused chunks of smaller volumes are lost, but also total backup size is a few times larger than it could have been.

TaylorB
Enthusiast
Posts: 47
Liked: 2 times
Joined: Jan 28, 2011 4:40 pm
Full Name: Taylor B.
Contact:

Re: +2TB sizes (again)

Post by TaylorB » May 02, 2011 5:23 pm

Gostev wrote:This is bad for dedupe and ultimately means excessive storage loss. Not just those multiple unused chunks of smaller volumes are lost, but also total backup size is a few times larger than it could have been.
It seems better than failing backup jobs to me. You gotta work with what you have.

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

Re: +2TB sizes (again)

Post by Gostev » May 02, 2011 5:40 pm

Spanned volume is just a better way to work with what you have.

yrrah2010
Influencer
Posts: 18
Liked: never
Joined: Jan 26, 2011 7:06 am
Contact:

[MERGED] Backup huge vServers

Post by yrrah2010 » Jul 13, 2011 7:59 am

Currently I have a virtual Veeam Backup & Replication server running, but I am struggling with backup huge 4+ TB servers.
This is my current configuration:
  • Create 3x 1,99TB LUNs on the storage (VMware limit 2TB -512b).
  • Create one VMFS volume with the 3 LUNs.
  • Create 3 separate virtual disks (VMware limit 2TB -512b).
  • Within the OS create a dynamic disk to create one big backup volume (because within Veeam you can choose only one driveletter).
Is there a simpler solution for this?

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

Re: Backup huge vServers

Post by Vitaliy S. » Jul 13, 2011 9:09 am

You may want to use LUN extents to store 4 TBs of data.

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

Re: +2TB sizes (again)

Post by Gostev » Jul 13, 2011 10:42 am

However, please keep in mind that backup into VMFS is considered bad practice for a number of reasons (you can find more details on that in the existing discussions). I would recommend to backup to NTFS formatted LUN of iSCSI NAS instead (via software iSCSI initiator). This will give you up to 16TB target (NTFS limit).

yrrah2010
Influencer
Posts: 18
Liked: never
Joined: Jan 26, 2011 7:06 am
Contact:

Re: +2TB sizes (again)

Post by yrrah2010 » Jul 13, 2011 12:16 pm

Gostev wrote:However, please keep in mind that backup into VMFS is considered bad practice for a number of reasons (you can find more details on that in the existing discussions). I would recommend to backup to NTFS formatted LUN of iSCSI NAS instead (via software iSCSI initiator). This will give you up to 16TB target (NTFS limit).
If i use the iSCSI initiator from Windows 2008 R2 I can't use MPIO active\active only active\failover.
The ESXi iSCSI initiator is much faster with throughput, and i don't have a vm port group configuration on iSCSI network because i only want the ESXi layer to handle storage IO.

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

Re: +2TB sizes (again)

Post by Gostev » Jul 13, 2011 12:43 pm

Sure, performance is important, but what is the sense in nice and fast backups if you cannot restore from them during disaster, and do it quickly?

yrrah2010
Influencer
Posts: 18
Liked: never
Joined: Jan 26, 2011 7:06 am
Contact:

Re: +2TB sizes (again)

Post by yrrah2010 » Jul 13, 2011 1:14 pm

Gostev wrote:Sure, performance is important, but what is the sense in nice and fast backups if you cannot restore from them during disaster, and do it quickly?
Time to move over to vSphere 5 :mrgreen:
VMFS-5 supports volumes up to 64TB
This includes Pass-through RDMs!

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

Re: +2TB sizes (again)

Post by Gostev » Jul 13, 2011 1:19 pm

There might be one small issue with this suggestion though, as vSphere 5 is not released yet :D

mpozar
Enthusiast
Posts: 30
Liked: 1 time
Joined: Jan 01, 2006 1:01 am
Contact:

Re: +2TB sizes (again)

Post by mpozar » Oct 26, 2011 5:46 am

A file thus the .vmdk in vSPhere 5 is STILL limited to 2TB according to the VMware vSphere 5 Configuration Maximums document.

Have FUN!

Michael

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

Re: +2TB sizes (again)

Post by Gostev » Oct 26, 2011 9:24 am

Yes but we have been talking about LUN and pRDM sizes - and they indeed can be up to 64TB with vSphere 5.

lobo519
Expert
Posts: 297
Liked: 34 times
Joined: Sep 29, 2010 3:37 pm
Contact:

[MERGED] Backup Repository W/ MS iSCSI Initiator

Post by lobo519 » Jan 26, 2012 3:56 pm

Is anyone using the MS iSCSI initator inside a guest OS to host a Backup repository on a VM? I am trying to get around the 2TB limit in VMware.

Good? Bad? Performance?

Thanks!

rmiller
Novice
Posts: 5
Liked: 1 time
Joined: Dec 19, 2012 3:33 pm
Full Name: Ryan Miller
Contact:

[MERGED] backup repository - single striped volume or multip

Post by rmiller » Dec 19, 2012 3:40 pm

I am at a customer and we are configuring the Veeam server (Windows 2008 R2) as a VM, and using DAS storage that is attached to the vmware cluster via SAS. Total DAS storage is ~16 TB, which has been presented to VMWare as a single LUN, and a datastore has been created. We are using ESXi5, so the file size limitation is 2 TB for virtual disks added to the Veeam server.

My question is whether there is a general preference for either:
1) Aggregating multiple 2 TB LUN's at the OS level as a striped volume (or spanned? I'd assume striped is better for I/O purposes) to have fewer Veeam repositories, or
2) Keeping each 2 TB LUN as a basic, MBR disk and being a separate Veeam repository

I'm sure there's some degree of style to go with one or the other, but I'm trying to determine if there are major gotchas with either one. For the former, I see the major downside as being less flexible, and the latter I see the major downside being more administrative overhead with having to balance backup jobs among the various repositories. A hybrid option may be to aggregate 2 x 2 TB LUN's together into 4 TB chunks, to maintain flexibility while not having quite as many smaller repositories (making backup job balancing easier).

Thanks!

rmiller
Novice
Posts: 5
Liked: 1 time
Joined: Dec 19, 2012 3:33 pm
Full Name: Ryan Miller
Contact:

Re: [MERGED] backup repository - single striped volume or mu

Post by rmiller » Dec 19, 2012 4:24 pm

rmiller wrote:I am at a customer and we are configuring the Veeam server (Windows 2008 R2) as a VM, and using DAS storage that is attached to the vmware cluster via SAS. Total DAS storage is ~16 TB, which has been presented to VMWare as a single LUN, and a datastore has been created. We are using ESXi5, so the file size limitation is 2 TB for virtual disks added to the Veeam server.

Thanks!
Or (based on others' comments after my question was grouped with this thread) - is it highly recommended not to have the veeam storage go through vmware, and instead have it be a RDM?

Post Reply

Who is online

Users browsing this forum: jmmarton, Karinne and 46 guests