Backups, i need some guidance.

Soldato
Joined
7 Jun 2003
Posts
16,188
Location
Gloucestershire
Overview of what we're got:
At the moment I've got Backup exec 2012 which i don't like, the interface changes from 2010 feel very cumbersome and there's a lot of bugs hindering our backups.

Thing is our entire infrastructure is VMware ESXi 5.1, and we have only one physical server that isn't running ESXi....and that's the backup server with the LTO4 tape drive connected and backup exec installed. So all AD/SQL/Exchange servers are virtual.

All our file storage is replicated between two iSCSI units and is identical within two buildings along with volume shadow copies on both ends for instant file recovery (though I am aware this is not to be considered a form of backup) The main store everyone reads and writes to is mapped to the file server VM, currently via microsoft iSCSI initiator but that's changing to be an RDM soon. The other store is mapped to the backup server and DFSR keeps the files on both stores identical.

When we backup to tapes using backup exec we backup from the locally connected store to the backup server.

What I need to know:
So because my entire infrastructure is VMware based with no additional physical servers to backup, do i really need a program like backup exec or would i benefit more from a dedicated vmware backup solution such as veeam or vRanger? I know for example vRanger can do individual file based restores for example but can this drill down to the iSCSI presented stores on a VM and backup those files as well? or is this intended purely for the virual machine itself?

Overall we want rid of backup exec, we're sick of it, but if the answer is no we can't backup iSCSI based data from something that's intended for VM backups only then would my best solution be to use something like microsoft DPM in conjunction with a VM focused backup?

Last question....which i feel a bit silly asking but do programs like vRanger and veeam actually backup to tape? They never mention tapes so I'm just a bit curious as to whether they're intended just for backups to disk? Having never used anything like them yet I have absolutely no idea what to expect, i need to run a trial when i get time really.
 
Last edited:
You be better off with vmware snapshot backup of some kind, like veeam etc this will allow you to restore your vms without much hassle.

We use a combination. So we have snapshots of all vms going to a file store that is DFS to our DR site and we can fire up those snapshots at the DR at any time. Those snapshots run every few days in the night.

Then we our tape backup using lto 5 tapes and arcserve which is just like backup exec. We backup exchange using the exchange agent so that we can get full mailbox recoveries, this backup is every night.

Then we have our document management store which is now 900gb that is backed up every night to tape as well. This allows for files to be recovered in the case of an issue. The entire DMS store is also replicated to the DR side with DFS.

then we have sql backups going to the same file store which is also DFS across, then we backup the sql to tape every night as well. We do have some other things in the backup like network my documents folders and some other random document stores.

But we have a fair amount of physical servers that are not backed up. The sql is backed up and the server can easily be recreated and the db be added back in so we don't see a need to have a C: drive backup of a physical box in those instances.
 
Tape is in the Veeam roadmap but isn't there yet.

We use Veeam to back up our 5.1 estate.

Veeam/vRanger etc can back up anything that the vStorage APIs have access to - which means anything that VMWare is aware of can be backed up but with the usual caveats - RDMs need to have sufficient space in their containers to be snapshotted. If your RDMs are 2TB then you might need to think about that although 5.1 has made this a bit easier.

You'll still need to get your Veeam backups to tape if you want to be sure, we have ours set to produce Reverse Incremental backups and we send those to tape every weekend (and we keep two weeks worth of incs on the backup server).

I have about 60TB of storage dedicated to this though, so YMMV...
 
I think i need to take a step backwards and take a look at my storage solution in that case.

When you say RDMs need to have sufficient space in their containers to be snapshotted do you mean if i have a 2TB RDM and 1.5TB of that is used, it's unlikely i would have enough space for the snapshot? I'm unaware of how the snapshot sizes work really.

Also what's the time scale for a snapshot of 1-1.5TB roughly? and what sort of effect does a snapshot process running during daily operation have on disk usage etc? I'd assume it'd be quite an intensive task.

Trying to design an effective storage and backup solution on a tiny budget feels very difficult :(
 
I think i need to take a step backwards and take a look at my storage solution in that case.

When you say RDMs need to have sufficient space in their containers to be snapshotted do you mean if i have a 2TB RDM and 1.5TB of that is used, it's unlikely i would have enough space for the snapshot? I'm unaware of how the snapshot sizes work really.

Also what's the time scale for a snapshot of 1-1.5TB roughly? and what sort of effect does a snapshot process running during daily operation have on disk usage etc? I'd assume it'd be quite an intensive task.

Trying to design an effective storage and backup solution on a tiny budget feels very difficult :(

Not exactly - what I mean is that when you mount up your RDM, it will essentially "pretend" to be a VMDK by creating a mapping file inside a VMFS volume. Lets say your RDM is 1.5TB; when you take a snapshot, VMWare will check to see if there is enough space to store the snapshot if every single block changes during the snapshot. In this case you would end up with a 1.5TB snapshot. If you only had 500GB of free space, you'd be in deep water - so VMWare won't let you create a snapshot if it couldn't snapshot every changed block. I think this was introduced in vSphere 4.

http://kb.vmware.com/selfservice/mi...nguage=en_US&cmd=displayKC&externalId=1012384
 
Back
Top Bottom