Backup copy jobs and Fast Clone

[aantoniani]

Hi everybody,
I use Backup Copy jobs with GFS to produce long term retention of backups, and I use a single ReFS volume for both the Backup job and the Backup Copy job Repositories.

Doing it on a Backup Repository on the same ReFS volume as the source Backup Repository, I was expecting that the first run of the Backup Copy job would leverage Fast Clone of blocks from the source backup file so that the job would complete quickly and consume very little space.
That does not seem to be the case, and the actual situation is that we have kind of two different branches of block cloning, one for the regular Backup job and a different one for the Backup Copy job and used space is higher that what would actually be needed.

Has anyone suggestions on how to configure the Backup Copy job so that it does not duplicate blocks that are already present in the source Backup Repository?

[Shestakov]

Hi Alessandro,
Out of curiosity, what is the purpose of using same repository for backup and backup copy?
Thanks!

[aantoniani]

Long term retention, as a safety measure against wrong modification or deletion of data that is noticed weeks after it actually happened.
Is it so uncommon?

[foggy]

Hi Alessandro, this doesn't work as you expect, fastclone works within a backup chain only.

[Shestakov]

Foggy is correct, Fast Clone helps with increments and merges, but if you create another backup chain, the data will be copied.
As for using same repository for both backup and backup copy. It`s uncommon since the main purpose of creating a copy of backup is to secure it from data loss on primary repository. However it`s supported.

[EricJ]

As for using same repository for both backup and backup copy. It`s uncommon since the main purpose of creating a copy of backup is to secure it from data loss on primary repository.

This is true, except since you can't specify extended retention (weekly/monthly/quarterly/yearly) on primary backups, we have to resort to making an entirely new second copy on the same repository (very inefficient!), and then using GFS retention on that.

With storage prices dropping, I'd think more people (like myself) would want to have this ability. I mean, if the disk space is there, why wouldn't I want to retain monthly and yearly backups?

[Shestakov]

Eric, initial best practice was to have 2 copies of backup: short chain on the primary repository and longer chain (with GFS or not) on the secondary repository.
However, due to big amount of requests we are considering to add the option for primary jobs as well.
Thanks

[aantoniani]

Our situation is similar to that of Eric: we are taking backups offsite on tape, but it is very useful to have them online on disk storage, that makes it much easier and quicker to use in case of need.
So it would be nice to be able to block clone among different backup chains, as Veeam backup knows it is actually replicating existing data.

[Shestakov]

How often do you restore from the old backups?
Usually around 95% of restores are from last week backups, so tape looks like a good place for historical ones, GFS Media Pools are supported for that purposes.

[EricJ]

Eric, initial best practice was to have 2 copies of backup: short chain on the primary repository and longer chain (with GFS or not) on the secondary repository.
However, due to big amount of requests we are considering to add the option for primary jobs as well.
Thanks

That's great news - thanks!

Yes, I see where you're coming from in trying to ensure users have two separate copies of backups. And, like aantoniani, we do have a second backup location with tapes. Like you said, the majority of backups we do are from the primary repo - but we have the extra disk space, and fast cloning stores GFS copies much more efficiently, so why not make use of it? Also, our monthly and yearly backups are for long-term retention purposes, so having a second copy of those (on disk) would also offer more disaster resiliency.

In essence, the Veeam best practice would be "short chain on primary, long chain on secondary", but I think even better would be "everything on both".

[aantoniani]

How often do you restore from the old backups?
Usually around 95% of restores are from last week backups, so tape looks like a good place for historical ones, GFS Media Pools are supported for that purposes.

In our specific case, somehow often users notice something is missing or wrong weeks or months after it was actually deleted or changed. Adding fun, most of the times they do not know when it was last time that they saw it and it was correct.
So not only you have to restore terabytes of data from tapes to restore a file, but you may be doing the same over and over, going back in time to find the correct version of the file.
That makes a very good case for having historical backups online, also because they cannot wait more than a few minutes to have their file found and restored.

[Shestakov]

Eric, I see your point and it makes sense.
By the way, fast clone works with GFS restore points as well.

Alessandro, got it. The request is taken into account.
Thanks!

[mralc]

Eric, I see your point and it makes sense.
By the way, fast clone works with GFS restore points as well.

Sorry to jump on this thread, just to make sure i understand how fast clone work with GFS and copy jobs, So if you have a four week retention period, every time it create the full backup file it use fast clone?

[veremin]

Correct, unless you use active full method for GFS restore points. Thanks.

[jayscarff]

My question is how can you tell that your cloud connect jobs - pointed to reFS repo are actually doing fast clones?

Thanks

[veremin]

There must be [Fast Clone] tag in the job session. Do you see it?

[Tijz]

So fastclone is available for CSP’s offering their repositories through cloud connect?
And on the tenant side you can actually see if the csp is using it ?

[veremin]

So fastclone is available for CSP’s offering their repositories through cloud connect?

Correct.

And on the tenant side you can actually see if the csp is using it ?

Correct.

[jayscarff]

There must be [Fast Clone] tag in the job session. Do you see it?

I did, thanks, i was hoping to see it from the Service provider console, but figured it out after i'd typed the question! Sorry!

[jayscarff]

Silly question! I should have said can you tell from the provider side if the job is fast cloning easily?
I checked the tenant console and can see Fast Clone!

[veremin]

This information is not exposed at SP's end. So, you cannot easily get it, unless you parse repository data mover log. Thanks!