Suggestion to backup VM with newly attached large VMDK ?

[albertwt]

Hi All,

I'm currently planning to migrate one large VMDK from old VM into the existing VM that is running new 2012 R2 deduplication:

Old File Server VM - PRODFS01-VM:
Windows Server 2008 R2
C:\ 60 GB - OS
D:\ 1.9 TB - Production File Server drive 1
Veeam Backup Job - File Server 1
Repository drive: Backup Server1 drive L:\ 200 GB free

I will detach the 1.9 TB VMDK disk above and then attach it into the new VM as below:

New File Server VM - PRODFS02-VM:
Windows Server 2012 R2 - All NTFS Drive is deduped except C:
C:\ 80 GB - OS
D:\ 1 TB - Production File Server drive 2
E:\ 750 GB - Marketing File Server drive 3
F:\ 955 GB - Engineering File Server drive 4
Veeam Backup Job - File Server 2
Repository drive: Backup Server1 drive K:\ 860 GB free

but the problem is that both of the existing Backup repository is not capable to hold 1.9 TB, so can anyone here please suggest me to backup the new 1.9 TB drive after it is attached on the new File Server VM ?

Thanks.

[foggy]

Not sure what your options are except adding more storage to repository.

[albertwt]

Hi Alex,
Somehow the disk shelf is already at the capacity on the server, I can't add more disk shelf and I can't add extra SCSI controller card on the server.

If I continue with attaching the disk to the new VM, I guess the backup will be failed due to not enough disk space despite the deduplication is already reducing the disk space used.


Sent from my iPhone using Tapatalk

[ACC]

We dont use Windows deduplication for our Veeam backups but are using regular forward backups, we prefer to do this kind of switch on the day a new full backup is made that way the full backup masks the change. It does prevent the issue that Veeam dedup perhaps doesnt recognize the duplicate data and having us deal with a enormous incremental backup file. That would be our advice make the switch on the day the new full backup is made, if youre using forever forward and dont have enough free space to handle the temporary additional backup storage requirements i dont have clue how to solve this issue without adding storage as Windows dedup is postprocessing. If you cant add direct attached storage to the server but have nics unused, perhaps iscsi is option to add storage to the backup server.

[foggy]

If I continue with attaching the disk to the new VM, I guess the backup will be failed due to not enough disk space despite the deduplication is already reducing the disk space used.

Windows dedupe affects in-guest space utilization, while from the image-level backup perspective the disk size is not reduced.

[albertwt]

We dont use Windows deduplication for our Veeam backups but are using regular forward backups, we prefer to do this kind of switch on the day a new full backup is made that way the full backup masks the change. It does prevent the issue that Veeam dedup perhaps doesnt recognize the duplicate data and having us deal with a enormous incremental backup file. That would be our advice make the switch on the day the new full backup is made, if youre using forever forward and dont have enough free space to handle the temporary additional backup storage requirements i dont have clue how to solve this issue without adding storage as Windows dedup is postprocessing. If you cant add direct attached storage to the server but have nics unused, perhaps iscsi is option to add storage to the backup server.

Hi Acc,

All of my Veeam Backup job is using Reverse Incremental to maximize the disk space usage.
The entire 4x NICs (2x on board & 2x add ons) is currently used and configured with LACP to the core switch, the Veeam backup server in the other office also configured the same to achieve 4 GB aggregated bandwidth.

[dellock6]

You don't have to direct connect the iscsi storage to the server, it's enough that the Veeam server can reach the iscsi target via the network.

[ACC]

Ive did a little test with a reverse incremental job and moving a 25GB disk from VM1 to VM2 didnt have any effect on the backup size, so the Veeam dedupe engine caught the duplicate data. So if dont use the Veeam dedupe switch it on to prevent the large bulk duplicate data hitting your storage. However ive done nothing besides moving and mounting the disk, becarefull with making changes to the data as that will impact the dedup ratio.

[foggy]

Ive did a little test with a reverse incremental job and moving a 25GB disk from VM1 to VM2 didnt have any effect on the backup size, so the Veeam dedupe engine caught the duplicate data.

This is true for the case where both VMs are backed up by a single reverse incremental job (the data goes into the same full VBK file and gets deduped). In the OP's case the jobs and even repositories are different, so Veeam B&R inline dedupe will not help.

[ACC]

Ah, i missed that detail. Than its either additional backup storage or keeping both the old and new file server on the same backup volume and preferable in the same job.