New B&R solution

[mark_e]

Hi all,
New here to the community!

I am implementing a B&R solution for my company.
We set up a PoC which run very well, so we decided to give notice to our external backup provider to end this coming February.

We have bought a DL380 G9 with 2 x D6020 420TB 12GB I/O(840TB total) in RAID60
There is a dedicated 10GB line between 3 of our sites. The main DC is where all our virtualisation is located. The backup server will be located in our secondary location and in the future we will recycle some P2000 G3s to serve as a secondary backup location in our third site.

I wanted to get some ideas on what direction to take on peoples experience.
Just a few questions......
If using WinSvr 2012R2, whats the max drive size I should use? 360TB (per D6020, 720TB total) is presented to the OS.
Is it probably worth waiting out when Server 2016 GAs later this week or next to use ReFS 3.0?

Looking forward to some ideas!

Cheers,
Mark

[PTide]

Hi,

If using WinSvr 2012R2, whats the max drive size I should use? 360TB (per D6020, 720TB total) is presented to the OS.

That depends on your backup job settings. You should stick with the disk size that will allow your backup chains to fit into.

Is it probably worth waiting out when Server 2016 GAs later this week or next to use ReFS 3.0?

Personally I would not assign a role of a backup/repository server to an OS that had just been released.

[DaveWatkins]

If you want to run Windows Dedup at any point that has a max volume size of 64TB.

If you can afford the space loss RAID10 might also be a better options (assuming 7200RPM disks). Although ReFS 3 will help this, I/O can be pretty brutal to RAID5 and 6 type arrays
If you stick with 2012R2 see if you can leave a volume empty so you can upgrade to 2016 in future and format that volume ReFS, move an existing volumes data to it and migrate all of them over to ReFS eventually.

If it were me I'd look at perhaps running 2016 on the host of the P2000's and put ReFS there initially, use that as a backup copy location and see how it goes, it'll give you a fairly low risk way to test 2016 and ReFS 3 without risking your primary repository, after you're comfortable you can upgrade your primary repo host and look at converting those repos to ReFS 3

[Mike Resseler]

Windows Server 2016 with ReFS 3.1 (it has became 3.1 in the RTM version) is certainly worth a look. If you search on these forums you will find lots of information. For example: This holds great conversations: veeam-backup-replication-f2/veeam-next- ... 31-15.html

Deduplication in windows server 2016 (NTFS, no ReFS) has also received some improvements so certainly also worth the effort to try that out in your environment but as already stated, you are limited per volume with 64 TB for the volume size.

My personal preference would be to do some tests with server 2016 today, and certainly on the ReFS part. If I understand it correctly, you have until February. So the moment it hits GA, I would do some PoC testing with ReFS (for a month or so) and see what it does (my testing has already gone very well, and that was on TP5, not even on the RTM or GA version, still need to find time and do some work on the RTM version ). I personally have become a big fan of ReFS and what you can do with it in conjunction with B&R, but that also means that you need to wait for v9.5 to come out of course

[mark_e]

Some great suggestions here guys, so thanks very much.
Just a question in regards to dedupe. We are going to go with RAID10 for performance reasons, I have also been told that if we need more storage, we can get some. So my question is, is there a benefit in doing dedupe on WinSvr 2012 if we can buy more storage as required? Especially when B&R does its own form of dedupe?

[Mike Resseler]

Windows Server 2012 / 16 dedupe is per volume while B&R dedupe is per job (but if you choose per-VM option, which is certainly interesting if you use server 2016 dedupe, but the dedupe will be less with B&R). The downside of server 2016 dedupe is that it is post-process and you do need the resources to run it.

I like the results of server dedupe but you need to plan accordingly.

[DaveWatkins]

If extra disk space isn't a problem to get I'd leave Windows Dedup off personally. Even with the improvements in 2016 it's a) extra load and b) will slow down restores. There is also file size limitations which are fairly easy to exceed even with per-VM chains on. I much prefer the idea that the data physically on my disks is the actual data needed to restore.

In saying that format the volumes with the /L and /A:64k just in case

[mark_e]

Thats the answer the boss was looking for! Cheers. Seen the /L /A:64 quite a few times, so they will be used.

[Delo123]

Happy dedup user here. Over 4 years in production and since implementing /L we haven't seen a glitch until now (multiple 4TB+ backup files) and also running replication from dedup repositories.
Biggest reason for us to run dedup is unlimited retention (2 backups per day since 2010)

PS C:\Windows\system32> get-dedupstatus

FreeSpace SavedSpace OptimizedFiles InPolicyFiles Volume
--------- ---------- -------------- ------------- ------
48.23 TB 81.37 TB 372 372 O:
43.42 TB 99.09 TB 8589 8589 R:
44.35 TB 26.48 TB 10 11 S:
50.49 TB 67.57 TB 407 407 Q:
49.77 TB 47.49 TB 4471 4471 P:
36.93 TB 65.38 TB 197 198 T:
55.72 TB 40.05 TB 3761 3761 V:

[Gostev]

Are you happy with restore times from deduped backups, particularly Instant VM Recovery or mass file level recovery performance?
Or do you keep all new backup files undeduped for some time, so that most restores are performed from raw files?

[Delo123]

Not really, but we also aren't very happy running restores and especially instant recoveries not only from deduped volumes. Firat landing zone is flash, than non deduped. Scale out repository helped very much in backup placement which is cool. Testored in general seem the be the achilles heel of veeam, not sure how competing parties are doing here. Not sure if it's the nfs mount or vmfs in general but iops and even full restores seem to be quite slow. We opt for booting replicas instead of instant restores for multiple reasons. 1st replica's are on "real" redundant storage and the vm will run normally. Instant restores never seemed to be working really well for us like if there is the slightest issue there will be no retries etc. and veeam will simply shutdown the vm thus losing all deltas. Also vmotion from instant recoveries gave us some pain because it sometimes failed when doing the vmotion all disks at a time, doing rhem one by one went a bit better however. I hope 9.5 will be better at this... but to come back to the point we don't see much difference in deduped and non deduped backups. Arestore from a backup with a lot of increments gives a same feel for random io and the bottleneck never seems to be the source (backup repository)

[ian0x0r]

Interesting comment about the vMotion not working if you do all disks at once. I would need some one to confirm but from experience I think there is a 24 hour timeout on the migration. If the migration took longer than this, then the sVmotion would stop.

[Delo123]

Yes, that's possible. But we also had cases where svmotions were certainly under 24 hours. The thing is these are usually "high stress" situations. Getting support during this is mostly impossible as it will usually take 2 or 3 days for support to get really "aware" and then the usual things are asked / checked. Mostly it will look like network connectivity but we are pretty sure it isn't. It seems to be a somewhat fragile connection, especially with heave loaded systems. WHat bothers me most is when instant recoveries are for some reason interrupted (may it or not be the infrastructure) all changes are lost, that's somewhat a no go (at least for us)