How to handle indefinite backups?

[itguy1024]

Our organization wants to keep exchange backups indefinitely (weekly full / daily incremental).

Our server is about 600GB, daily incrementals come out around 5-20GB. From what I have read this seems normal for exchange servers.
So far we have 180 restore points coming in around 15TB. It seems like we are going to need to allocate 30TB a year just for exchange backups if we want to keep them forever.
I have the compression level set to extreme and storage optimization for wan.
Is there maybe a better way to do this?

Have 4 weeks of backups rolled into a monthly and 12 monthly's rolled into a yearly? I'm not sure if that's possible or if it would save on space.

I looked at GFS but I'm not sure I understand it correctly or I would gain anything from doing it that way.



TIA

[foggy]

Hi Scott, this tool will help you with sizing: https://rps.dewin.me. If you do not need to keep backups for every day, GFS is what you need as it allows you to keep weekly/monthly/yearly restore points according to your needs. I also suggest looking into some sort of deduplication on the backup repository to save space - what is your target storage, btw?

[itguy1024]

We would need daily backups.

The Veeam server runs on an M240L with local sas storage.

Would this be a good article to use for dedupe?
https://www.veeam.com/blog/data-dedupli ... veeam.html

[itguy1024]

With the storage doing dedupe should Veeam be set to none for compression level or dedupe friendly?

[Mildur]

If you have Windows Server 2016 or 2019 and local SAS Disk as a backup repo, i recommend to use reFS filesystem and Veeams Feature FastClone. I don’t like the Windows Dedup feature.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Wit FastClone, a synthetic Full Backup will only need the space of your daily incremental. The other „blocks“ from the vbk, which doesn‘t have changed, will be reused from the already used space on the disk.

[itguy1024]

I don't have the option to rebuild the file system.

[foggy]

With the storage doing dedupe should Veeam be set to none for compression level or dedupe friendly?

For Windows Deduplication - yes, for ReFS - no.

[Mildur]

If you want to use Windows server deduplication for saving backup space, then please follow this best practices:
https://www.veeam.com/kb2023

You will need to leverage „per VM Backup Files“
I see in your original post, that you have a 15TB backup over all vms. With windows deduplication, it‘s not recommended to use it with backup files over 1TB. You will face performance issues.
„Per VM Backup Files“ needs at least a Enterprise Edition license from VBR (or VUL).

—————-

15TB only the exchange. I have misread that, sorry.

[itguy1024]

Foggy - Yes to which one? None or Dedupe Friendly?

[foggy]

Both are possible - you can try and compare what gives better space saving in your case.

[itguy1024]

Well I tried the Windows de-duplication as recommended and it has crippled the performance of my Veeam server. Attempts to undo the de-duplication process have failed so far.
Full synthetics take days to run now. The Dedup chunk store has used almost 4TB of much needed space that I have yet successfully recovered. Running any kind of PS commands to do recovery just hose the system.

I don't recommend anyone use Windows Deduplication.

[skrause]

If you are going to use Windows Deduplication you usually want to do periodic active fulls rather than running synthetic operations. It also takes some tweaking of the DeDupe job schedules, including when to perform the garbage collection to be most efficient. If you don't schedule the garbage collection to align with your retention/full backup schedule properly (run GC right after the previous chain is deleted but before the active full happens) you will likely run out of disk space. Though in the permanent retention model, if you set your dedupe optimization to only look at files that are more than 8 days old you shouldn't have as many issues with the synthetic operations slowing way down because of re-hydration.

We used Server 2012R2 Deduplication for years in our previous datacenters without much in the way of problems after figuring out the pitfalls.

If you are not planning on ever deleting daily incrementals ( ) then just running an active full every week or two and then having your deduplication run should give you some pretty good long term space savings in theory.

Windows Dedupe using "chunklets" instead of straight up file level or block level deduplicaiton can lead to either really good performance or really bad.

[itguy1024]

I got the really bad performance end of the deal haha.

Still continuing to try and undo the deduplication that's been done to clear out the chunk store.

Unfortunately running any garbage clean up or unoptimize commands just sit at 0% and queued status indefinitely.

[skrause]

Your best option in cases like this is likely to robocopy the files to another volume that does not have windows deduplication turned on rather than doing unoptomize.

[itguy1024]

So I uninstalled everything to do with windows dedupe on Server 2016, deleted the volume and rebuilt it. Still awful performance. 22MBs compared to before where I was getting 300MBs +

I can run a Windows file copy to the volume with great speeds (R & W). But Veeam just falls on it's face using it.

Open to any suggestions on how to restore performance.

[veremin]

You might want to reach our support team and let them check the debug logs and find the bottleneck in your backup environment that results in dismal performance rates. Thanks!

[itguy1024]

Solved.
Adding these reg keys seems to have done the trick.

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\
Key: UseUnbufferedAccess
Type: REG_DWORD
Value: 0

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\
Key: DisableHtAsynclo
Type: REG_DWORD
Value: 1