+8Hello everyone,
We plan to backup an exchange dag 2016 in close future, this dag is not small (400tb).
We face many technical challenges:
What storage are you using for the first tier? I’m covinced the airgap should be tape storage due to ransonware/rampage protection and large storage capacity of lto9.
I’m curious to have a review about the exchange backup challenge 
Disclairmer: i’m not an exchange expert
Best answer by ejenner
Release of version 11 is coming imminently. It’ll probably be generally available before you’ve had time to procure and configure hardware and software for this project so it would make sense to plan to use version 11 from the get-go. Veeam releases are unlike Microsoft releases in the sense that they are tested prior to release… haha. I can’t think of a time any of the features I regularly use being compromised by a version release.
Anyway, the new version gives you the ability to create an immutable disk based repository on a specially configured Linux server. Disk is actually very similar to tape in terms of cost these days, so why make life hard for yourself with tape.
The main concern when it comes to the 400tb size you have will be restore time in a DR scenario. Day to day backups will be manageable on basic hardware as only incremental backups are taken after the first full backup.
So you must find out from a discussion with the organisation owners what their cost v.s. restore time priorities are. If being able to recover their entire exchange environment very quickly is of the utmost importance then they’ll have to spring for a replica environment which will mirror the performance of their primary production hardware. Anything less than that will see slower, possibly unacceptable performance. In this configuration scenario you would configure replication through Veeam. The failover time is very quick, not instant… but almost instant.
If they would rather spend less and accept the slower restore time they can get something cheaper. You could provide a middle road where you have a copy of the system which can be brought live very quickly and a different backup to restore the databases slowly while the live system allows people to continue working with new emails. This route requires some careful consideration and thorough testing to get it working properly.
The ideal configuration to assist with fast restorations if you cannot do replication is to utilize an off-host proxy server with a repository directly attached local to the Exchange server data. Connect this into your SAN backbone rather than depending on the LAN or WAN. The directly attached disk provides a local copy which can be restored quickly. For full data protection you would have to copy the contents of the local disk to your off site repository.
Release of version 11 is coming imminently. It’ll probably be generally available before you’ve had time to procure and configure hardware and software for this project so it would make sense to plan to use version 11 from the get-go. Veeam releases are unlike Microsoft releases in the sense that they are tested prior to release… haha. I can’t think of a time any of the features I regularly use being compromised by a version release.
Anyway, the new version gives you the ability to create an immutable disk based repository on a specially configured Linux server. Disk is actually very similar to tape in terms of cost these days, so why make life hard for yourself with tape.
The main concern when it comes to the 400tb size you have will be restore time in a DR scenario. Day to day backups will be manageable on basic hardware as only incremental backups are taken after the first full backup.
So you must find out from a discussion with the organisation owners what their cost v.s. restore time priorities are. If being able to recover their entire exchange environment very quickly is of the utmost importance then they’ll have to spring for a replica environment which will mirror the performance of their primary production hardware. Anything less than that will see slower, possibly unacceptable performance. In this configuration scenario you would configure replication through Veeam. The failover time is very quick, not instant… but almost instant.
If they would rather spend less and accept the slower restore time they can get something cheaper. You could provide a middle road where you have a copy of the system which can be brought live very quickly and a different backup to restore the databases slowly while the live system allows people to continue working with new emails. This route requires some careful consideration and thorough testing to get it working properly.
The ideal configuration to assist with fast restorations if you cannot do replication is to utilize an off-host proxy server with a repository directly attached local to the Exchange server data. Connect this into your SAN backbone rather than depending on the LAN or WAN. The directly attached disk provides a local copy which can be restored quickly. For full data protection you would have to copy the contents of the local disk to your off site repository.
Hi
First, you can position HPE Nimble or a similar product as the primary backup repo unit.
As the second backup unit, you can position a product such as HPE Storeonce and copy your data to this unit and reduce your disk cost with the deduplication feature.
Finally, you can keep your backups cold for a long time in the cloud environment as offsite or in an archiving unit.
Hi there,
originally (Veeam 8) we had a 2010 DAG with about 5TB for the Database copies. This DAG running on VM did just have 2 members so that each time it came to the vm consolidation step, exchange users dropped their outlook connection or something similiar happened.This DAG has then been expanded with an additional Member which did just hold the database copies from the other active members. Also an Load Balancer was installed by this time, to avoid that logons or sessions are done by the third member holding the database copies. This member has also all needed Roles installed and active but the load balances keeps load away from it, as long as the other members are active and databases are healthy. This did work for us till Veem 9. Then data did grow, the netapp primary storage we did use at this time was too slow etc.At this time we did purchase a small Nimble Storage to move the third member to it and do Exchange backus with storage snapshots. Actually we have 2 DAG with 3 members each and about 12TB of data (just database copies) migrating from exchange 2010 to 2016. Primary storage is a powermax 2000, since then there has never been an performance issue again, but unfortuantely there is no direct storage support from veeam, so that good old nimble is still in charge to handle storage snapshots, quite slow compared to the powermax but reliable.Full Backup taken every month once:Allowed timeframe: 36h on weekendBackup runtime: 2:30hProcessing rate: 803MB/sBottleneck: SourceData Processed 13,4VM Size 17,9Just noted numbers so that you can make your own calculations on 400TB.So from that, what was my expience with Exchange backups (thats why I mentioned the waypoints from veeam 8 to 10) I would start with your given backup time window for a full backup. Sure you woun’t do often real full backups but for me it is more save to calculate with this because nobody want’s to have unhappy Exchange/ Outlook customers on the phone. If you have a 10GBit Network infrastucture, then 1,1GB/s is the maximum you can expect, so to backup 400TB would take about 89h. This is obviosly to long for a backup time window. So you will have to do more in parallel, if you are able to split these 400TB to 100TB on 4 different dag members, stored on 4 different storages (nimble or purestorage to have an good Veeam integration and performance) writing to 4 different repositories then a full backup would be done in 22h without impacting customers. But this scenario depends heavily on your infrastructure and how much money you want to spend.
+14That's a huge amount of emails ;)
I would have suggested to backup only a single database copy but I see you're already calculating with the actual data. Your DAG will probably be spread over multiple sites with different hardware/storage/infrastructure; so availability shouldn't be a problem.
The backup solution will depend on what you're trying to achieve; availability, disaster recovery and/or data security. Also the SLAs matter, like
It will be the best to contact Veeam for support of a senior SE who can help you sizing the backup environment.
+8Hey Everyone, we finally did the design.
For an exchange monster (450tb):
One physical server (Apolo gen10 4200) per DAG, the server is backup repo and backup proxy.
Tier 2 Glacier Like
+8Hey Everyone, we finally did the design.
For an exchange monster (450tb):
One physical server (Apolo gen10 4200) per DAG, the server is backup repo and backup proxy.
Tier 2 Glacier Like
Immutable Linux using XFS based Fast Clone for your physical servers? :)
Object storage with tiering on tape is cheaper 
+8Hi
First, you can position HPE Nimble or a similar product as the primary backup repo unit.
As the second backup unit, you can position a product such as HPE Storeonce and copy your data to this unit and reduce your disk cost with the deduplication feature.
Finally, you can keep your backups cold for a long time in the cloud environment as offsite or in an archiving unit.
Hello
+14+8We ‘r not in the same scenario, exchange are not VMs. Windows hosts are on Apolo Gen 9 4u FULL HDD with 4*25gb :)
Can’t wait to be able to make some tests hehe
+23Hey Everyone, we finally did the design.
For an exchange monster (450tb):
One physical server (Apolo gen10 4200) per DAG, the server is backup repo and backup proxy.
Tier 2 Glacier Like
Immutable Linux using XFS based Fast Clone for your physical servers? :)
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
