I have Server 2012R2 virtual server that is used to store SQL backup data. The virtual server is Vmware 6.5.The SQL backups are ran from a few different SQL server and stored on four different drives on the 2012R2 virtual server. The drive sizes are 2.3TB, 2TB, 600GB and 700GB. The virtual server is backed up with Veeam 8.5 update 4. The total size in Veeam for the virtual is 6.2TB which included the four drives, the OS drive and one other drive that is 250GB.
The backup job for the 2012R2 server runs fine. The issue that I am running into is once the backup is completed the job runs the merge job which can take up to six days to complete. With the SQL backup jobs that run while the merge is still processing the backups never catchup.
Is there a more efficient way of configuring the backup job? Can I backup just the SQL backup drive and not the OS drive? Or should I create other Vmware servers in order to split up the backups to different servers to decrease the size of the backups overall?
Any suggestions would be helpful.
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Aug 13, 2020 8:53 pm
- Contact:
-
- Veeam Software
- Posts: 3626
- Liked: 608 times
- Joined: Aug 28, 2013 8:23 am
- Full Name: Petr Makarov
- Location: Prague, Czech Republic
- Contact:
Re: How to Make a Large Backup Smaller
Hello,
Basically, it makes sense to deploy a faster target storage because six days for merge is too long even for workloads having a high daily change rate.
I think you have the following options with your current repository:
1) To schedule periodic active full backup instead of using forever incremental chain. The daily merge is no longer needed but obviously active full run will take significant time.
2) To make horizontal scaling of SQL server and to split up the jobs.
A couple of thoughts regarding slow merge:
1) I would recommend to upgrade Veeam B&R to the most recent version and to install this update.
2) You may want to ask our support team to investigate the issue a bit deeper, probably they would find something else that slows down the merge. Maybe it's not related to the target storage performance.
I don't recommend to exclude OS drive especially since its size is just 250 Gb.
One more suggestion is to take care of transaction logs.
Thanks!
Basically, it makes sense to deploy a faster target storage because six days for merge is too long even for workloads having a high daily change rate.
I think you have the following options with your current repository:
1) To schedule periodic active full backup instead of using forever incremental chain. The daily merge is no longer needed but obviously active full run will take significant time.
2) To make horizontal scaling of SQL server and to split up the jobs.
A couple of thoughts regarding slow merge:
1) I would recommend to upgrade Veeam B&R to the most recent version and to install this update.
2) You may want to ask our support team to investigate the issue a bit deeper, probably they would find something else that slows down the merge. Maybe it's not related to the target storage performance.
I don't recommend to exclude OS drive especially since its size is just 250 Gb.
One more suggestion is to take care of transaction logs.
Thanks!
Who is online
Users browsing this forum: Majestic-12 [Bot] and 29 guests