BackupCopyMirrorAll behaviour

[mrmagicman]

So if we wanted to copy all existing restore points to another repo, we can use BackupCopyMirrorAll.

However, will this now need to rehydrate (I guess more a compression term but it works) all the existing backups (we use XFS) and then store that amount of data on the secondary repo? i.e., if we have a source repo that is using logically 100TB (but only has say 20TB of physical space), then on the secondary repository it will use 100TB of space?

Or is this the restriction/downside on using BackupCopyMirrorAll?

[david.domask]

Hi mrmagicman,

The registry value you're discussing doesn't impact the rehydration of fast clone'd/deduplicated files, it simply instructs the Backup Copy Job on how to handle the backups it intends to make copies of.

You are correct that moving dehydrated data to a new volume, the data will be rehydrated. If the target volume supports fast clone or deduplication, Veeam operations will be "aware" of these features and fast clone/dedup will be applied as usual when writing, but the data will be rehydrated for transit.

So it's not about the registry value, it's about moving dehydrated data to a new location, which will happen regardless of this registry value.

Can you share a bit more on the target repository? Does it support fast clone also?

[mrmagicman]

Yes the target supports XFS.

So just to clarify, if you don't have this reg key inplace before you start a BCJ, then with a source repository and lots of restore points, it will only copy the latest and essentially just start the secondary copy from the time you create and start the BCJ, correct?

If I use the reg key and then create the and start the BCJ, it will copy every restore point currently in the source repository, right?

I'm just trying to understand the copy process and whether we will maintain the effective logical vs physical free space if we copy all the restore points from the get go.

[david.domask]

Correct, without this registry value, Backup Copies only act on the most recent and new restore points. With the registry value, the initial run of the Backup Copy will process all restore points in the source chain and make a copy.

[mrmagicman]

So I guess the question still remains in terms of space.

If I have a current repository with 100 restore points. It currently consist of 100tb of logical space thanks to fast clone but uses only 20tb.

If I was to copy all the backup restore point data out to some external disk it would take 100tb of space as the xfs magic on the repo allows it to only be stored using 20tb of space.

My question is in terms of BCJ and copying every restore point. Does this mean I have to have 100tb of disk space or does a BCJ use XFS in such a way that it will copy all the restore points and still only use 20tb on the target repository? I.e does it still use XFS magic when copying every restore point using that regkey