Hi
I have 2 sites,site A and B. In each site there is a share folder to work as repository for Veeam Backup.
Two site connected to each other using 6mbs link.
Virtual machines backup regularly without any problem and each site store backup file in his share folder.
Now I plan for the offsite backup by using synthetic backup for example Virtual machines of site A store on repository of site B.
I created a job include these parameters
Week day- Incremental backup
Weekend - Synthetic backup
I also chose WAN in storage optimization of Job .
I chose synthetic because of network bandwidth limitation.
In fact by choosing synthetic backup on weekend it should be transfer incremental and initial full backup to a new backup file and it doesn't need a high network bandwidth but it uses a lot of network bandwidth. what is the problem ?
Also it took days to transfer full backup. I don't know why!
Can any one explain to me why does it happen ?
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Apr 21, 2018 3:20 am
- Full Name: Seyed Yahya Zahedi Fard
- Contact:
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Transferring Full Backup (Synthetic Full) is so slow
Hi and welcome to the community!
Could you provide the jobs statistics so we know how much data was read, processed and transferred?
By the way, have you considered using backup copy jobs instead of another pair of backup jobs?
Thanks!
Could you provide the jobs statistics so we know how much data was read, processed and transferred?
By the way, have you considered using backup copy jobs instead of another pair of backup jobs?
Thanks!
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Apr 21, 2018 3:20 am
- Full Name: Seyed Yahya Zahedi Fard
- Contact:
Re: Transferring Full Backup (Synthetic Full) is so slow
Hi Shestakov
Thanks for your kindly responsibility. I have attached two picture which comprises job statics as you requested.
https://www.dropbox.com/s/6fmosa8ys2fx4 ... t.png?dl=0
https://www.dropbox.com/s/0u387yzgf15ff ... 1.png?dl=0
By the way I am thinking on second solution you mentioned, because I didn't know any thing about it but at the moment I am studying about Backup Copy.
Thanks!
Thanks for your kindly responsibility. I have attached two picture which comprises job statics as you requested.
https://www.dropbox.com/s/6fmosa8ys2fx4 ... t.png?dl=0
https://www.dropbox.com/s/0u387yzgf15ff ... 1.png?dl=0
By the way I am thinking on second solution you mentioned, because I didn't know any thing about it but at the moment I am studying about Backup Copy.
Thanks!
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Transferring Full Backup (Synthetic Full) is so slow
Thanks.
In your case bottleneck is not network bandwidth, but "target".
"Target" is the target (backup storage) disk writer component. Percent busy number for the target component shows percent of time that the target disk writer component spent writing the data to the storage. Your target storage speed is presenting a bottleneck for the whole data processing conveyor, because all the pending I/O operations cannot complete fast enough, and due to that there is always some data waiting in the incoming queue of the network component that is waiting to be written to disk.
Backup copy jobs use forever forward incremental method that requires less IO operations, thus will work faster.
In your case bottleneck is not network bandwidth, but "target".
"Target" is the target (backup storage) disk writer component. Percent busy number for the target component shows percent of time that the target disk writer component spent writing the data to the storage. Your target storage speed is presenting a bottleneck for the whole data processing conveyor, because all the pending I/O operations cannot complete fast enough, and due to that there is always some data waiting in the incoming queue of the network component that is waiting to be written to disk.
Backup copy jobs use forever forward incremental method that requires less IO operations, thus will work faster.
Who is online
Users browsing this forum: Google [Bot] and 25 guests