Hello!
I have been using Veeam 6.5 for a couple of weeks now.
We have:
- Daily backup (Only on weekdays. ) Processed data is 1.6TB Transferd data is 63GB and Takes about 1.5 hours
- Week backup (Full backup every Sunday) Processed data is 1.6TB Transferd data is 100GB and Takes about 7 hours
- Replication between two sites (every day) Processed data is 1.1 TB and Transferd data is 27GB and takes about 11-12 hours (10Mb VPN between the 2 sites)
In the replication not all vm's included.
The daily backup starts at 17:30 every day
The Replication starts at 19:30 every day. If the replication takes to lang I have to kill it. If i don't nobody on the other site can work.
Before we had two Netapp's. On every site one. And also we had ShadowCopy every 2 hours between 8:00 en 22:00 hours.
My Questions:
- Can we speed up the backup en replication? because i think it takes to many time.
- Can we make more often a backup? (whitch not takes a hole lot more storage)
- What can i do to reduce the size of the backup
We also have a Qnap storage with PST files and Photos and a total size of 165GB. this i would like to add to the backup in the future.
But I think we do have a problemen with replication because it takes more time.
Thanks!
-
- Novice
- Posts: 3
- Liked: never
- Joined: Jun 25, 2013 1:37 pm
- Full Name: Ivo van Raaij
- Contact:
-
- Product Manager
- Posts: 20415
- Liked: 2302 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Backup and Replication questions
Hi,
Firstly, what are the bottleneck statics for these jobs?
Secondly, kindly take a look at corresponding job session statistics and see whether CBT is being leveraged or not (search for special “[cbt]” metrics)
Thirdly, where you replica metadata is stored?
Foruthly, you can group VMs in such in order that VMs created from same template or VMs that have same OS will be backed up within the same job. This will guarantee better deduplication rate that is likely to reduce the size of corresponding backup data. Also, you might want to use extreme compression level, though, please be aware that with the latter option backup/replication jobs might take some time to complete.
Thanks.
Firstly, what are the bottleneck statics for these jobs?
Secondly, kindly take a look at corresponding job session statistics and see whether CBT is being leveraged or not (search for special “[cbt]” metrics)
Thirdly, where you replica metadata is stored?
Foruthly, you can group VMs in such in order that VMs created from same template or VMs that have same OS will be backed up within the same job. This will guarantee better deduplication rate that is likely to reduce the size of corresponding backup data. Also, you might want to use extreme compression level, though, please be aware that with the latter option backup/replication jobs might take some time to complete.
Thanks.
-
- Veeam Software
- Posts: 21139
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Backup and Replication questions
I also wonder about your primary storage and the transport mode used to retrieve VMs data from it during backups and replication and whether you have proxy server in the target site for replication.
-
- Service Provider
- Posts: 182
- Liked: 48 times
- Joined: Sep 03, 2012 5:28 am
- Full Name: Yizhar Hurwitz
- Contact:
Re: Backup and Replication questions
Hi.
Please provide more details, such as:
Hardware in use (production storage, backup storage, backup server, and more).
How many VMs?
Jobs setup: how many backup jobs? Do you have a single "daily backup" job for all VMs?
Size of VBK files?
Number of concurrent jobs? if you run a single job at a time, you can consider parallel processing by running 2 jobs at the same time.
This can shorten the total backup/replication time, because - part of the backup/replication time is used to prepare guest, commit snapshots, and other tasks that the backup server is waiting for completion. When you run 2 concurrent jobs, there will be much less "pause time".
You can even run backup and replication jobs in parallel, by planning the schedule in a way to avoid overlapping.
For example :
17:00 start backup job 1 = VM1-VM10
18:00 start backup job 2 = VM11-VM20
19:00 start replication job 1 = VM1-VM10 (not starting earlier to avoid problems if users stay late at remote office).
20:00 start replication job 2 = VM11-VM20
Some jobs will run in parallel - by design. You can limit it by configuring proxy and repository for maximum concurrent jobs, for example = 2.
You can even configure the same start time to several jobs whenever applicable.
Regarding replication - I think that a 10mbps is too slow for your current deployment (capacity/bandwidth/backup window).
You can reduce number of replica VMs, and/or split them between days.
For example: half VMs replicated at even days (Mon,Wed,Fri), and the other half at odd days (Tue,Thu,Sat).
In the future you can plan to increase bandwidth .
Also consider the new wan acceleration feature to improve wan usage (however in the coming release it will work only for wan backups, not wan replica).
Please provide more details, such as:
Hardware in use (production storage, backup storage, backup server, and more).
How many VMs?
Jobs setup: how many backup jobs? Do you have a single "daily backup" job for all VMs?
Size of VBK files?
Number of concurrent jobs? if you run a single job at a time, you can consider parallel processing by running 2 jobs at the same time.
This can shorten the total backup/replication time, because - part of the backup/replication time is used to prepare guest, commit snapshots, and other tasks that the backup server is waiting for completion. When you run 2 concurrent jobs, there will be much less "pause time".
You can even run backup and replication jobs in parallel, by planning the schedule in a way to avoid overlapping.
For example :
17:00 start backup job 1 = VM1-VM10
18:00 start backup job 2 = VM11-VM20
19:00 start replication job 1 = VM1-VM10 (not starting earlier to avoid problems if users stay late at remote office).
20:00 start replication job 2 = VM11-VM20
Some jobs will run in parallel - by design. You can limit it by configuring proxy and repository for maximum concurrent jobs, for example = 2.
You can even configure the same start time to several jobs whenever applicable.
Regarding replication - I think that a 10mbps is too slow for your current deployment (capacity/bandwidth/backup window).
You can reduce number of replica VMs, and/or split them between days.
For example: half VMs replicated at even days (Mon,Wed,Fri), and the other half at odd days (Tue,Thu,Sat).
In the future you can plan to increase bandwidth .
Also consider the new wan acceleration feature to improve wan usage (however in the coming release it will work only for wan backups, not wan replica).
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 71 guests