Thoughts on changing backup strategy when using ReFS

[btmaus]

We used to have our daily/weekly/monthly/yearly backup jobs and GFS jobs going to a dedupe appliance.

Now that we have migrated to a Windows 2016 ReFS repository for our daily jobs, we are seeing better performance and we are thinking of changing our strategy from keeping 7 daily restore points, 4 weekly restore points, and 12 monthly restore points.

If we change to keeping 30 daily restore repoints on the ReFS respository, and 12 monthy restore points on the dedupe repository., I could remove the need for the 4 weekly restore points on the ReFS repository, which would save alot of space and processing time.

Thoughts on this from the experts? What am I missing?

[Mike Resseler]

Glenn,

It is clear that you will have more granularity with the new strategy. But there are a few things you need to keep in mind

1) I hope you used 64K for ReFS? There are some threads here where 4K causes lots of pain for users
2) While ReFS will use block cloning API when you create a synthetic full (I would still do this) it will use less space, but I doubt that with your new strategy you will need less or equal space so make sure you have the storage available. In the end, you are still maintaining a full, lot's of incrementals, and then the (weekly?) synthetic fulls which should be indeed spaceless for most part.
3) make sure you have a method for testing your backups (Surebackup!) because if there is corruption on a block that is referenced many times, you could lose a lot

Hope it helps
Mike

[btmaus]

Thanks for replying Mike.

1) Yes 64K and I haven't seen any issues.
2) My weekly full's at the moment consume the full amount of space as they are not synthetic. The reason I was thinking of changing to keeping the increments was to decrease the space used. What do you suggest then as per #3 I'm worried about the long backup chain.

[foggy]

What do you suggest then as per #3 I'm worried about the long backup chain.

Enabling health checks and testing backups with the help of SureBackup is always recommended.

[kubimike]

I do daily full synthetics, wouldn't block corruption get detected then from the incrementals ? 6 Incremetals a day + full synthetic on one backup job. I retain 540 recovery points.

[btmaus]

I do have the backup file checks enabled for the GFS copies.

I do daily full synthetics, wouldn't block corruption get detected then from the incrementals ? 6 Incremetals a day + full synthetic on one backup job. I retain 540 recovery points.

If I go with keeping 30 restore points for the daily backups, and a weekly synthetic full, would that help detect any corruption issues?

[Mike Resseler]

Glenn,

Maybe I scared you unnecessary too much (on the other hand, I never joke around data and keeping it safe ).

I would suggest you start testing with health checks and SureBackup. I guarantee you are going to love it. No matter what method you are using, there is always the possibility that data corruption occurs. But with those 2 you should sleep well at night. Especially with SureBackup, that means the VM can boot and tests can be performed (ping / SQL tests / any other script you want to run against the VM)

[btmaus]

I will check it out