We're rethinking our backup strategy and would like some input from others that run VBR.
Previously we were running all our backup to NTFS with deduplication. But we have had a few problems with NTFS and deduplication where we run into NTFS limits and defragmentation and need to restart the backup job. This was with v8 with one file per job. We also had a few restores from the NTFS where deduplication has caused the restore to take for ever.
My idea is:
- Backup VM to ReFS storage for fast restore. Retention for about 14 - 30 days. This is the primary backup server.
- Backup the same VM to another server for long time rentention. 1 year with syntetic or active full ever 90 days. Using NTFS and deduplication.
Pros and cons with using this method instead of Backup Copy Jobs from the primary backup server?
I'd recommend you to use backup copy job, here are a few major considerations:
1. By using two backup jobs you will increase the workload on production significantly.
2. Long term retention policy named "GFS" was designed for the backup copy job, so you can set it up.
3. Scheduling between jobs will be much easier as copy job continuously looking for a new restore points at the source repository during predefined interval.
Also for your initial backup ReFS probably won't help. The reason I say this is that synthetic fulls don't give you much of an advantage with < 30 restore points. If I assume you backup once a day, then there wouldn't really be a need for synthetic fulls, and without those ReFS doesn't give you anything. If you follow Dmitry's guidelines, the repo used as a startget for backup copy jobs could potentially be a good candidate for ReFS usage.
I'd say that ReFS is more for fast backups rather than restores. People always remember space savings, but ReFS is also about IO savings if you use reverse or forward incrementals, with or without synthetic fulls, there's also the daily injection into the full file once you reach the desired retention. So, backups can be quicker as you close the snapshot earlier.
Luca Dell'Oca Principal EMEA Cloud Architect @ Veeam Software
Is there any issue with having two separate backup jobs for a single VM with their own repositories, retentions and possible copy jobs or will these get in each other's way. This is without using 'secondary destination' but two separate jobs altogether. They would be scheduled such that their snapshots would never step on each other.
The one thing I was wondering about is change block tracking would improperly show changes only since the other job's backup, not since the day before in the case of a single backup job that runs daily.
There are no issues expected in your case, however, I'd recommend you to use the backup copy job for such scenario.
Please review this existing thread for additional information.
The answer about the CBT you will find in the FAQ here. Thanks!
Thanks DGrinev. One of the goals in this test is to have separate chains tied to separate copy jobs and not tied down each other. If you have two copy jobs set to the same backup job, then when one copy job is running the other can't. They are inherently sequential. The other reason is we are testing two repo destinations and whichever ends up being the one we choose we want that chain to live on without having any ties to the other.
the backup job isn't a big IO hit when it runs so I'm not worried on the extra hit on production. it finishes in 10 to 15 minutes daily anyway.