ReFS: Moving Backup Copy Job to new ReFS Repo

[doggatas]

By the nature of Block Cloning the most disk space savings are had on the Full Backups. I need to move a bunch of GFS backups to a new Repo. If I have a Backup Copy Job sitting on a ReFS repo is there anyway I can move those files to another ReFS repo (different volume) and retain the space savings or once I copy those files off the ReFS volume they were created on, are they always written at their full size at the destination?

Regards,
David

[foggy]

Hi David, it's the second, copying files to another volume inflates them.

[doggatas]

Thanks. I will start a new backup chain on the new repo.

Regards,
David

[mkretzer]

Will that change in V10? I mean it is not really that unlikely that with a long GFS chain you have to change the hardware at some point and then you will loose all the space savings...

[foggy]

It is actually not specific to Veeam B&R, but to ReFS itself (think like volumes with Data Deduplication enabled).

[mkretzer]

I know - but can Veeam not find out if a block is cloned and move it with the reference to the new block address on the new volume?

[foggy]

No, there's no such copying functionality in Veeam B&R.

[GrNathan]

@mkretzer it's worth noting that the feature you are asking about possibly being added to Veeam v10 would more usefully be requested of Microsoft as a possible enhancement to the ReFS engine. Like @foggy mentioned, it's analgous to a volume that has Data Depulication enabled, where copy/move actions to other volumes will trigger 'rehydration' of de-duplicated data. Solutions to this are

1. Start a new backup chain, as original poster has opted for in this scenario.
2. Assuming sufficient available storage ( and IOPS capacity plus CPU time) on the new volume, copy the data from old volume to new volume and allow the rehydrated data to go through deduplication again.

Neither of these are pain-free scenarios, but thats why we pay careful attention when we do our capacity-planning work to avoid having to do too many storage-platform rip & replace operations, right?

[Henrik.Grevelund]

Hi there

There are a couple of times where it would be nice if Veeam had a "Move existing backup jobs intelligent":

-Migrating jobs from one REFS volume to another without re-hydrating them
-Rebuild the second or third copy with GFS jobs
--When a data loss occurs it would be nice to set Veeam to recopy the GFS points
---if the second copy is encrypted its not possible just to copy the local files since they aren't encrypted
-Move from one service provider to another without loosing GFS history

Have a nice day,
Henrik

[MikeK]

There is one way to accomplish this although it may not meet some of the requirements discussed here. It's actually quite simple ... you just have to think like a storage admin.

1) Disable your backups to the ReFS repo
2) ... Perform a "clone" operation of the underlying volume on the SAN. I say "clone" because many manufacturers call this something proprietary. Basically we're looking for an identical copy of the volume. It is also possible (again depending on your SAN) to clone to a remote location and a different SAN altogether.
3) Remove the original vol and map the new. It will look the same because it is the same.
4) Enable your backups

This would work to get through something like a storage refresh and installing new hardware. Sizing is important because larger vols require more time to clone. We are still putting ReFS through testing in our environment before deploying in place of NTFS. Having the ability to move data is critical. Backups with small chains can be reseeded but any type of extended retention complicates writing to ReFS when you think about the current challenges in performance, stability and mobility. One of the particularly interesting use cases is what Gostev mentions in his Jan 21 update and Archival. In a cost/GB model that you might use for Veeam Cloud Connect or and as we are evaluating, IAAS the possibilities are very exciting

[adapterer]

You can accomplish this with Windows Storage Replica if you have datacenter edition - https://www.virtualtothecore.com/en/win ... s-volumes/
Depending on your setup you could use Veeam agent to backup as it works at block level and restore to the new volume - but I have not tested this.

[ITP-Stan]

Using Veeam Agent's Volume Backup / Restore: That's a nice idea!
Can we get some confirmation this will work as intended?

[jandrewartha]

Someone also suggested disk2vhd which would probably be good for a once off. Veeam Windows agent for server has CBT for ReFS which would be necessary for repeated backups.

It'd be nice to having something that pulls the image, we're pondering ways to get an offline copy of our long-term (12mo+, 26TB atm) backup copy repository that's updated once a week, both for cryptolocker recovery and in case the whole server dies in a fire for some reason, we don't lose that backup history.

Right now I'm thinking a two stage backup, Veeam agent backup to our old netapp, then a small server that boots up automatically (BIOS/UEFI control?), copies the image over, emails success then shuts down again, but I'm sure this could be simplified.

[maxideus]

Hello,

I have a Backup Copy Job, approximately 10 TB worth of GFS backups, for 6 months (6 monthlies, 4 weeklies, 7 dailies). The data is currently residing on a NTFS repo. I want to take advantage of my ReFS repo for fast clone and spaceless storage benefits.

Is it possible to move the GFS files to the ReFS repo without rehydrating the data? Or would I need to start a new chain on the ReFS repo and need to maintain the existing data on its current storage for 6 months?

Any suggestions or pointers would be appreciated on how to leverage the ReFS repo without having to hold the old data on the NTFS storage for 6 months. My plan is to redo my Veeam Repo so that all repos are ReFS but I must evacuate the data first.

[PTide]

Hi,

Please check the existing thread for some ideas. Also here is a blogpost that might be helpful.

Thanks!

[ITP-Stan]

On NTFS there is no blockcloning functionality, so the VBK files created in that GFS schema are each their actual size, without space savings (regardless if it's Active Full of virtual).
You will have to start a new GFS copy job (with virtual fulls) and a new chain on the ReFS (64K !) repository to start taking advantage of the block cloning functionality.