Request Your Thoughts on this Backup Strategy

[mberry]

Hello,
I’d like to get feedback on possible issues with the following backup strategy using Veeam 7 Backup & Replication.

Background: I have a Windows 2012R2 VM running on VMware 5.5. It has two .vmdk files, the first stores the OS, the second stores our file shares (Network Shared Folders).
I want to be able to increase the frequency of backups on the files (second .vmdk) and decrease the frequency of backups on the OS .vmdk.

Goal: Reduce overall backup size on the repository while increasing backup frequency of Shared Folders.

Objective:
Create two backup jobs. The first job would run weekly (or monthly) and only backup up the VM and its OS vmdk, excluding the vmdk that is used for “File Storage”.
The second job would run nightly and backup up the VM but exclude the OS .vmdk and thus only back up the .vmdk that houses the Shared Folders. Will this cause any issues?


Any thoughts on how a similarly configured strategy for backing up an Exchange or SQL server would work?
We have the OS, Databases, and Logs stored on separate .vmdk files. Could you restore and Exchange server only (don’t start it on finish),
then restore the Log and Data backups, then start the Exchange or SQL server using this strategy?

Thank you for your thoughts, and your time!

[veremin]

Even though you can stick to the described approach for ordinary VMs (files servers, etc.), it's unlikely to work for VMs running transactional applications, such as SQL, Exchange, SharePoint, etc. In the latter case, the consistency will be a huge question. Thanks.

[foggy]

I would note that with system disk excluded from the job, you would not be able to restore to original location from the Veeam B&R console.

Also, I'm not sure whether this gives you a huge benefit from the overall backup size perspective, since system partition typically does not change a lot.

[mberry]

Foggy,

I considered what your saying, but I'm not sure it addresses my issue of long term archive?
If only the "data" drive is changing on a regularly basis (opposed to the OS drive) and my goal
Is to only archive relevant data? Wouldn't it make since to separate the OS from the DATA and only
archive the DATA drive? Why keep 10 years worth of identical copies of the OS? Each "backup-copy" will
include the OS and DATA if they are not separated.

Yes, no?

[Vitaliy S.]

Hi Mark,

You can definitely go with your original idea of backing up only "data" drive, however you should keep in mind that the restore process will require you to run VM disks restore wizard, you will not be able to use Instant VM recovery (as system drive will be missing), also no backup verification (SureBackup jobs) will be possible with this approach.

BTW, what is your target storage for these backups? If it is a dedupe target, then there should be no issue with keeping system drive for the same time as the "data" drive. If I were you I would configure a single backup job to backup the entire VM image. This would be a best practice approach, especially when you're backing up transaction-sensitive applications such Exchange Server/SQL Server.

Thanks!

[stevehathaway]

I have a client file server that has 2 data drives - both 2TB. One drive is production the other is archive.
I need to run 2 jobs due to space constraints & the need to copy to tape
Job 1: Backup the system drive & the 2TB Prod data drive daily (do not remove the excluded disk from the config)
Job 2: Backup the Archive drive only at the weekend

The question is for restores - we are not replicating & most restore operations will be file level. Should I check the remove excluded disks from the"Archive" Job?

In the event of a full VM recovery I would restore the VM with the production data first then restore the Archive separately before powering on the VM

Opinions?

[veremin]

Hi, Steve,

It stands to reason to check the posts provided above. Also, be aware that if you don't remove a given disk from a configuration, full VM restore will fail and you will have to adjust .vmx file manually.

Thanks.