Copying backups from one XFS Fast Clone repository to another

[aj_potc]

Case #05030159

I have a repository that uses XFS Fast Clone to help reduce the size of my GFS synthetic full backups. I'd like to migrate to a new repository and, if possible, retain my old backups and continue with the existing chains.

After searching here, I can see that there's no clear way to do this, as my XFS Fast Clone backups are filesystem-dependent. Since I would be moving them to a new filesystem, they would "rehydrate" to their full size, which is many times larger than my space available.

Support suggested I might create a SOBR with two extents: one being the old repository, and another one being the new one. Then I could try to evacuate the old repository, thereby causing Veeam to copy the backups for me. However, this doesn't work, as Veeam complains that there's not enough free space on the new repository. I assume it's counting the full size of each full backup, and not taking into account the Fast Clone savings.

Is this attempt to save my old backups a dead end?

I love the XFS Fast Clone feature and the resource savings it brings, but it's making it impossible for me to migrate away from an old repository and decommission that server without losing my backups.

Thanks for any help.

[pirx]

I doubt that evacuation will keep the data reflinked. This a common question and I searched for a solution myself. Other than dd or xfs_copy I don't know what could work. And those two need the source and destination to be identical in size AFAIK. If you can keep th old repository/extent until the retention time is over you could just add a new extent and seal the exiting one. When the old extent is empty you can remove it

[aj_potc]

Thanks for your reply. This seems to be a not-uncommon problem, and I suspect it will become more common as people take advantage of the savings from reflinking/Fast Clone in their repositories.

I'm sure that sealing the extent is the official answer, but I'd like to retire the old repository rather than keeping it around and online. It's a shame that there's no way to migrate those old backup chains while somehow retaining or recreating the reflinks.

[veremin]

Currently the data will be "rehydrated" during evacuation process, as Pirx' described. However we are aware of this limitation and thinking how it can be addressed in future releases. So thank you for sharing your feedback; your vote has been counted.

[vmJoe]

The easiest way that I have found to migrate to a new repository is to add the new repository to the Veeam backup server then point your jobs to it. If you have your jobs configured to use "days" for retention points then they old backup points will age out of the "old" repository. If they are set to use the "restore points" retention system then you can go into the maintenance tab and set the remove points after a certain number of days.

The new repository will use block cloning for all backup files moving forward.

[aj_potc]

Thanks for the tip, Joe.

In my case, I'd prefer to get rid of the old repository entirely, so I really need to migrate those GFS backups rather than letting them age out. That process would take many months based on my GFS settings, so I'm afraid it's not practical.

[tsightler]

The only method to do so today is via a block level copy like DD or xfs_copy, or some other block based method, as mentioned previously. If the new storage is not the same size you can still do the copy and then just resize the partition/logical volume and filesystem after the copy is complete and then continue to use that, at least as long as the target is larger than the source.