Using Backup window to terminate jobs

[rfn]

Hi,

Because of some strange issues (and user error I guess) I'm forced to create a new full backup of a very large (19 TB) VM. If possible then I would like the backup to "pause" during work hours, simply because the proxies pull so much data from our SAN that it's noticeable by our employees. If I specify a backup window that terminates the job before it's finished is the work that has been done then lost or does it just continue from where it stopped the next time the jobs starts?

Regards,
René Frej Nielsen

[dellock6]

The job is failed if you stop it via backup window. At next execution it will be executed again from start, not resumed.
Also, be aware on such large VM, at the time the backup window is reached, Veeam stops the job and requires vCenter to close the snapshot. But it can happen on such large VMs the snapshot could take some time, and the final commit will be noticeable too, and it will happen even few hours after the job has been stopped.
Just a suggestion, set the backup window to stop the job a little before users arrive, or they will be hit anyway by the snapshot commit.

Luca.

[rfn]

Thank you for the explanation. It's actually not explained very well in the documentation.

I started the job a couple of hours ago, just to see how long time it would take and my calculations suggests that it takes around 27 hours which is quite perfect because then it will be finished late monday evening so the snapshot commit won't bother anyone.

I have sent out an email explaining the situation and hopes that it doesn't make to much impact on the performance so that I can keep the job running tomorrow. It's moving a little more than 200 MB/s so the network ports on the repository is maxed out and and the network is probably quite busy as well... Luckily these source data are located on disks that are not used to store VM's so it might not affect the SAN performance much.

[veremin]

Also, if you haven’t done it yet, it might be worth upgrading to the version 7 and putting into use new parallel processing option. With the introduction of this option, VB&R can process multiple VMs and VM disks in parallel, this’s supposed to reduce significantly backup window.Thanks.

[rfn]

I'm already at version 7 and that does indeed make quite a difference. I think it's the reason that we're able to process 200 MB/s because if it was only one disk that was processed at a time then we could only process 100 MB/s since that's the limitation on our 1 Gbit/s network. With two disks being processed (by two different proxies) then we can get twice as much because the repository has a two nics teamed which allows it to receive 200 MB/s.

It's now at 51% after 15 hours so it still seems to complete during the night which is perfect.

[veremin]

Glad to hear that newly introduced mechanism has, indeed, increased performance rates, since it’s exactly what it was designed for. Anyway, kindly, keep us updated about the results you get. Thanks.

[rfn]

It went well, the 18,9 TB was backed up in a little more than 28 hours and took up 15,8 TB on the repository. The source is a Windows Server 2012 file server with deduplication enabled which is probably why Veeam can't compress the data more.

The job ended with a warning because of the large file and it tells me to make sure that the repository supports extra large files. I searched the web and it seems that Windows Server 2008 R2 - which is what the repository server runs - only supports files up to 16 TB . Is that correct?

Do I really need to either install Windows Server 2012 or choose a higher compression in Veeam and redo the job?

[veremin]

It’s more about NTFS limitation - as implemented, the maximum NTFS file size is 16 TB minus 64 kB or 17,592,185,978,880 bytes. So, switching to windows server 2012 seems reasonable, if you’re going to store the files that typically exceed the said limit. Thanks.

[rfn]

Thanks... . It seems like the the combination of deduplicated volumes on Windows Server 2012 and the faster, but less efficient, new "Optimal" compression has made the backup grown a couple of TB's. Not a problem that I expected

I guess that I could split the job but I would really like to be able to restore this VM in one job if ever necessary. I guess that Windows Server 2012 is the best solution.

[Vitaliy S.]

As far as I konw ReFS doesn't have this limitation (16 TB max file size), so you may want to start switching to this file system on your new servers or upgrade your Windows Servers 2008 to Windows Server 2012.

[rfn]

I haven't been able to find any clear information but some sites seems to suggest that NTFS in Windows Server 2012 supports the same large file sizes as ReFS. Do you know if that's the case?

If we switch to Windows Server 2012 on the repository then I might just go with ReFS to eliminate any future limitations. For now we only have around 200 GB left before the VBK file is too large

[veremin]

It appears that the previously existed file size limit has been overcome in Windows 2012. Thanks.

[rfn]

Nice with a confirmation. Thanks!

[rfn]

I'm actually considering setting up a Windows 8 workstation and attach our storage to that and make that our repository to overcome this limitation. I can't reformat the current repository server because there are other services running on it at this moment.

The link suggests that NTFS in Windows 8 also supports larger files but I haven't been able to confirm it anywhere else.

Is there any disadvantage in using Windows 8 instead of a server OS?

[foggy]

Is there any disadvantage in using Windows 8 instead of a server OS?

No issues with using Windows 8 as a repository server.

[rfn]

Great... I'll give a try. What would the correct procedure be to move the repository? I want to avoid having to create full backups...!

Should I move the storage to the new "server" and register it with VBR without touching the registration of the old server so that there's to repositories with the same data (although they're missing from the old) and then point the existing jobs to the new server and THEN remove the old server from VBR?

[foggy]

René, please follow these instructions to move backups to the new repository server.