Hi there...I have an existing repo presented to Win2012 server via iSCSI. My volume maxed out and I am left with 2 options...either move the contents to another volume and reformat the volume(8k or 16k) or go the scale out repo route.
If one was to go the scale out route which policy would work best? My current repo has 1 FULL active on there and all increments, I would like to keep it that way as I really dont want to run another full backup which is the default behavior when "pointing" to a new repo. Looking at the KB it looks like performance would be the way to go.
"If you set the Performance policy for the scale-out backup repository, Veeam Backup & Replication always stores full backup files and incremental backup files that belong to the same backup chain on different extents"
Hi John,
if you make backup repository a part of Scale-out backup repository, you will be offered to update a link to the backup repository in the job properties. So in any case you don't need to re-create Full backup.
As for policy, both are good. If you have only 1 job pointing at the repository, indeed "performance" is a better option.
Thanks!
I have many jobs pointed to existing repo...my only concern or question was which policy to use...the repo that is now full would has the fulls and increments so the new repo(part of the scale out) would be empty and I was trying to determine if a new FULL would be added since the repo is now an extent.
We are currently running SOBRs with 10 and 6 extents each. Depending on the timing of your backups and the size of the data. You could theoretically add the new repository and evacuate the data from the current repository to the new one. Time would vary depending on many things, network connectivity, workload, data size, etc. VEEAM has this as an option once the SOBR is created.
As far as the policy that we are employing, we are using the data locality policy for the reason that if an extent is lost we only lose certain portions of the backup chains. We would still have something that was recoverable
If you were running all of your Full backups to one location and that was lost, all backup chains and incremental restore points would be useless. Unfortunately it becomes the lesser of two evils, losing a few chains and time periods versus recoverability of all vms.
The other thing that makes this interesting is that we are running weekly Active Full Backups, this is nice in the SOBR structure because when a new full backup needs to be written, VEEAM looks at the extent with the most free space and will write the backup there as well as the following chain until another full is run and it will again look for the extent with the most free space and it creates a balance between the two. This is specific to our scenario and I hope it helps. I noticed that when we were on forever forward incrementals the chain would stay on the same extent until a new Active Full backup was written, which at that point would look for the extent with the most free space.
Also, as mentioned above you would need to point the job to the new SOBR for mapping of backup files if this was done.
If the extent with the previous backup chain is accessible, new full backup will not be triggered - during the next job run incremental backup will be placed on the new extent regardless of the policy.