VBR Upgrade Question

[sconley]

Currently our environment consists of a single VBR VM with an iSCSI attached NTFS volume acting as the repository and a single proxy server each running on Windows Server 2012 R2. I would like to upgrade to 9.5 to be able to take advantage of the REFS integrations, which means running server 2016 on the repository server. What is the easiest/best way to accomplish this?

[Gostev]

Install Windows Server 2016, format the required volume with ReFS, and create NEW repository on this ReFS volume.

[sconley]

Do I need to trigger a synthetic full on our existing jobs to actually make use of the fast clone technology, or just copy files? I thought I had read that a synthetic full would be necessary in another thread that I can't locate now. Also, wouldn't this mean that the connection to the new repository server would be limited to the network between the VBR VM and the repository?

I am trying to figure out if it wold be better to spin up a new instance of VBR and migrate everything, or just add a new Server 2016 VM as an REFS repository after upgrading our existing server to 9.5.

[ashleyw]

We are running a REFS repository on a Windows 2016 VM (4 GB ram ,2xCPU). If the VBR VM and REFS repository are on the same physical hypervisor, then the network traffic will stay local so shouldn't be a bottleneck (at least its not in our environment). You really want to run an active full on the new target and the strategy to move will be determined by how much spare space there is on your SAN.

[sconley]

Good point about keeping everything on the same underlying physical host. Storage should not be an issue, but how would the active full effect our backup chain? I have never quite sorted this part out. We keep 30 restore points for all of our VMs. If I do an active full, how long would it take before the previous full and all existing incremental backups rolls off? Would a synthetic full achieve the same thing?

[Gostev]

Fast cloning only works for backup files newly created in ReFS repository by the backup job, but how they are created does not matter.

[foggy]

If you're using forward incremental, old full with the corresponding increments will be subjected to the specified retention, so will be deleted once the new chain reaches 30 restore points.

[sconley]

We are doing forever incremental The only reason for the active/synthetic full is to be able to take advantage of fast cloning. So, the incrementals would not be cleaned up per the retention? If I am understanding this we would effectively need double the amount of space because of the active full (the entire chain becomes effectively a restore point in itself). Is this right?

[foggy]

Yes, you would need additional space for the full and subsequent increments. Probably not double, since active full will not be fragmented as the existing one, so will likely take less space.

[sconley]

I think I have a solid handle on everything now, and we have formulated a plan to move forward. Thanks for all the input.