ReFS and Fast Clone without Active Full Backup

[DaveWatkins]

Hi

I'm in the process of converting our repository to ReFS on 2016 and I'm currently clearing a LUN so it can be reformatted. I'm moving (just via robocopy) all the backups over to another volume that's already ReFS and I'm noticing [fast clone] in the job logs for some of the jobs. At this point it looks like about half of the ones I've moved are using fast clone.

I was under the impression I would have to do an active full to get that functionality enabled. Is it possible I've just luckily copied them and they match up across the right boundaries to make this work or is it a bug, and if so, does it indicate I'm not getting clean backups?

I do plan to do active full's to all the jobs but I have to get all the LUN's converted over first and the data redistributed to have enough space for that. I'm mostly concerned that the backups may be corrupt at this point.

Thanks

[Gostev]

Hi, Dave. Do you have compression disabled on those backups? Thanks.

[DaveWatkins]

Hi Anton

Nope, they are Reverse Incrementals with Compression set to Optimal and storage set to Local Target. Dedupe, exclude swap and exclude deleted are all enabled. As mentioned it's only affecting some of the jobs as others copied the same way aren't reporting fast clone

Thanks

[Gostev]

OK. May be it's something specific to reverse incremental jobs that I am missing. I will check with the devs and let you know if they'd like to see the logs. Thanks!

[Gostev]

Well, they have a theory but it requires many stars to align so does not seem likely to me... so we decided to just take a look at the debug logs. Please let me know the support case ID once you've uploaded the log package. Thanks!

[DaveWatkins]

Case ID# 01992536

[Gostev]

Thanks, forwarded.

[DaveWatkins]

Sadly the response from support was that the first backup will always be a full unless I mapped the backups, which I did. Also the logs would indicate of a full backup was taken and I know it wasn't since we are using reverse incremental backups and a) I don't have space for anymore than one full at the moment while I'm emptying LUN's, b) if it has done an Active Full automatically it would affect all my jobs, not just 4 out of ~12 and c) I would have an additional VBK which I don't.

Shouldn't all this be in the logs I uploaded?

[Gostev]

Sorry, perhaps the support is just trying to figure this out on their own - you should have told them you've already escalated the case into R&D through me.

Devs reviewed your logs and we did find the missing piece. Everything is OK, and the reason is actually much simpler than we thought. It appears that shortly after you've done migrating your backups to ReFS volume, compact operation was triggered by the schedule on some jobs, which created the new VBK that full meets the requirements for fast cloning. And considering that with reverse incremental backup, only VBK and the latest increment are participating in merge, fast cloning immediately started working for you.

So, feel free to close the support case since all is well in your case.

[DaveWatkins]

Ahh, that makes sense, fantastic

[DaveWatkins]

One more thing to add, that process would actually make migration to ReFS volumes much easier for anyone using Reverse Incremental backups. It removes the requirement for Active Full's and the space they would take and all it would take is a little extra time for the scheduled compacts to happen

[dellock6]

You discovered a nice trick indeed. Still the repository will consume a decent amount of IO to do the compact, but no IO will be consumed on the production storage to make the active full, thanks for sharing this discovery.

Luca

[DaveWatkins]

Presumably that I/O is going to happen anyway during the next maintenance compact anyway. While you could change the compact schedule to hurry the process just leaving it alone to happen during the next one anyway won't increase I/O at all. You just won't get the I/O benefits of ReFS until that happens.

On that note, were there any compact performance increases in 9.5 (or are any scheduled in 9.5U1)?. That's probably our biggest issue on a day to day basis currently, even with per-VM chains our exchange VBK files are still ~2.5TB each

[Gostev]

Yes, big improvements thanks to parallel processing added.

[gulzar.shaikh]

How to confirm that after upgrading veeam from 9.0 to 9.5 , the new APIs are making use of block close feature.? Is there any command or something to confirm?

[Gostev]

You will see [fast clone] tag next to synthetic full operations in the job log.

[Mike Resseler]

Gulzar,

Before you can start using block clone functionality of ReFS, you will need to have a windows server 2016 with an ReFS volume (a new one) and then use that volume as a backup repository. From that moment on it starts to vary. You can either move your backups from your old repository but then it won't start using that functionality because you will need to have an active full first (we need to write it correctly first before we can do this) or as you can read above (in case of a reverse incremental) you can use the compact utility.

Mike

[ptoro]

FAST CLONE IS AWESOME!!!!!!!!!!!

What used to take 3 hours took 5 minutes. PERFECT!!

Also, did have to take a active full backup in order for fast clone to work next time around. All in all, can't complain about the results.