In a comment on my recent article on Exchange Server 2013 lagged database copies Chris wrote:
I do not see any advantage in a lagged copy of a database. If any kind of corruption happens on a database we still have daily backup of the active DB which we can “activate” very shortly.
With lagged copy of a database, you still need a passive copy for high availability, you will end up with two copies of each database + the backup the active one . For me it is a waste of storage for what it brings.
This is a point of view worth considering. Certainly for some organizations lagged database copies won’t add much value. Either the scenarios they are designed to protect against are not considered to be a high impact event, or the risks are mitigated in other ways (such as traditional backups).
For other organizations the logistics of restoring data from traditional backups make lagged copies more attractive, as the data is already available and within the control of the Exchange administrators without needing to engage with other teams or third parties.
And for organizations where traditional backups aren’t used (which includes the Exchange Online service within Office 365) lagged database copies form a part of the Native Data Protection capability of Exchange Server 2013, which eliminates traditional backups.
What do you think, are lagged database copies a waste? Or do you see them as a valuable feature that you already use (or want to use) in your environment?
I’m still trying to figure out what kind of “corruption” will be transferred from one DB to another by way of transaction log replication. When did that become a thing? Once a TL is corrupted, that can’t be replayed on another DB, so where’s the risk of db corruption?
Secondly, in a 2 DC scenario, the chances of you losing ALL 4 COPIES is less than my chance of hitting the powerball lottery. With single item recovery enabled, I don’t see a need for traditional backups, regardless of using the lagged copy. If I’m wrong here, I’m open to hearing what I’ve missed.
My reason for having a traditional backup vs. lagged copy is that upon completion of backup the logs get truncated. without backup i believe the only other option would be to enable circular logging for each database but is that recommended? Also for any reason if lagged copies have issues and not in a healthy state, i would be very nervous since there is no backup in case i love an active copy. but that’s my 2 cents, i am sure every environment can be different.
It depends on your configuration.
In a recent Exchange environment I worked on, there were two datacenters with 12 mailbox databases in each datacenter (24 databases). These databases were all members of a single DAG.
There were 12 secondary copies in the same datacenter as the primary copy (24 secondary databases) and 12 lag copies from the databases from the *OTHER* datacenter (24 more lagged copies)
The way this system was designed is that if one datacenter went off-line, the other datacenter would come back up quickly by enabling the lagged copy of the offlined datacenter databases. Sure, there would be some log playback, but that would be minimal since there was already a full lagged copy of the database already there.
Since email is a mission critical app, this design allowed for quick response incase of a datacenter failure!
This also allowed us a buffer incase there *WAS* a corruption. In a primary/secondary, any corruption will be replicated. With a lagged copy, we can recover quicker than restoring a backup…which can be 500GB-1TB in size in our configuration!
I’m not convinced that lagged copies replace traditional backups.
How does it help in this situation
7 day lagged copy and 21 day single item recovery.
User manages to delete a number of folders but doesn’t realise for 8 days.
Single Item Recovery gives you the items but not the folder structure which is still important for a lot of users.
Saying “Tough Luck” works if its junior staff but if its the MD or their PA I don’t care what data retention policy the business and/or MD signed you are in trouble!
I understand your point; however, we are pushing our users away from folder organization methods and to rely more on search technology. I guess we are lucky that we don’t have some of the stringent requirements that some companies may have on restoration. We may push lagged copies out to 14 days, but for now, with our monitoring solution and offsite lagged copies, we feel comfortable with 7 days.
Lagged Copy is your Tardis but can only time-travel several days back. It is more valuable in large Exchange system like hosted Exchange or cloud services who has better monitoring system but smaller time window for logic corruption recovery.
We are a large manufacturing company with 7,000 mailboxes moving from Exchange 2007 to 2013. We are moving away from traditional backups and SAN storage to Exchange Native Data Protection and local JBOD storage for a few reasons:
1) We have no long term email backup requirements. Users can maintain 21 days of email using Single Item Recovery.
2) We are saving a substantial amount of money on traditional backup licensing that can be reinvested into better storage capacity and resources for the environment.
3) We are following Microsoft’s preferred architecture for DAG copies – 4 copies. Our lagged copy (DR site) is set at 7 days lag.
4) Each physical server has a spare disk for autoreseed.
I agree, it’s a very circumstantial decision, but for us, it made a lot of sense. I’d be interested in any recommendations on lagged copy configuration. I’m not sure if 7 is right or wrong. I have also set our lagged copies to not auto-activate. I prefer to control this.
I am jealous of you and your company:).
Ransomware rendered your thinking obsolete!
I think lagged databases are good if you have not a backup infraestructure in place. But if you have it I think this would be redundant.
Hi there,
I think it’s ah waste of ressources for the most environments, because:
– you need in every DAG one more server (storage etc.)
– you need more knowhow in your team for restore (or for the activation process)
– you get more complexity
– when did you got your last event 1018 logged?
– you need to proof your management that it realy works 🙂
– (or you still do regular backups)
Maybe more.. 🙂
I would like to point out:
1. Your first point is not correct, you don’t need a dedicated additional server to host lagged copies.
2. Your second point, don’t you think those skills are crucial for an Exchange admin?
3. You get less complexity by removing traditional backups, and therefore less non-native things touching your databases.
Hi Jeremy,
What is your setup for Exchange Native Data Protection? What are your time thresholds? What do you use for monitoring?
I am actually still in planning and pricing mode. But to answer, it is going to be a business decision between 1 or 2 weeks replay lag and I’m undecided about truncation lag.
As for monitoring, I don’t have anything fancy up my sleeve, just SCOM, decent control plan, and users who will contact support when something has gone wrong. But detecting logical corruption is the same difficulty whether you are doing backups or using lagged copies.
For me it is the cost of traditional backups and length of time required to backup and restore that make lagged copies more viable. You can activate a lagged copy instantly and let logs play in as fast as they can but people aren’t down and out. If a db is that bad – lagged copies win over backups. If you need to restore a user’s mailbox , you can take a copy of the lagged db and Mount it as a recovery db (gotta clean it with eseutil first) .
Basically lagged copies are like free backups with better and equivalent options than backups.
Traditional backups win when you need >14 days and can afford the monetary and administrative costs required for that…
I see very few (if any) good scenarios to combine lagged copies with traditional backups. It’s one or the other in my opinion. Lagged copies are there to mitigate the risk of logical corruption in a database and to go back to a point in time. If there is a traditional backup this can be used for the very same thing.
In a native data protection environment I can totally see the purpose of lagged copies BUT I’m not always convinced that they will useful due to difficulties in collecting information as when did the logical corruption occur. Not to mention the rather complicated operation to restore from them.
We’ve just completed our research on this very point and decided to forgo a lagged copy to protect our DBs. Our reasoning was based on the following:
1. Passive server/DB(s) is off site.
2. DBs are protected by IBM TSM TDP and EE (for file level), with nightly copy. (NOTE: we are moving this backup to the passive server to reduce overhead and to increase full copy frequency to 2x daily and then possibly adding incremental copies as well (aiming for 4 hour RPO)…so using this existing tool, we achieve similar results of lagged-copy).
3. Comfortable with AV/malware software running on mailbox servers and therefore conclude replication of infection is remote and therefore acceptable risk.
4. OS and Exchange are kept patched-current.
5. Exchange’s native check for logical corruption that occurs as part of log copy to passive server reduces likelihood of replication and there is acceptable risk.
6. Our mailboxes are spread across multiple DBs and therefore are manageable size and can be restored relatively quickly with the TSM TDP.
Environment is all physical with active and passive MB server and active and passive HT/CAS servers. Running Exchange 2010, SP3RU7. Have CAS Array for load balancing.
I would be very interested to learn any problems anyone may note with the 6-points I noted above. I’m relatively new to Exchange administration and am confident there’s something I’ve overlooked. Hope my comments help. Thanks,
Hi Paul,
at first I want to say a great THANK YOU for your work and publishing so many helpful things to us. We have about 14000 Exchange users and sometimes we have the need to restore a single mail, folder or mailbox. Of course there is the possibility to do this with deleted items feature, but sometimes it is easier for the user to recover the needed items if he can see i.e. the whole folder from yesterday and compare it. I think this method is much more flexible than a classic restore. Think about the scenario that a user says he had deleted a folder on monday last week. If you do a classic restore from sunday and the user says than “Oh, I think I deleted the folder 2 days before”, you have to do the same thing again. In the case of a restore via lagged database you only have to import the log files till sunday.
Christian
Why would you want to restore a lagged db for a few users that deleted something? The restore affects everyone.
I really don’t see any advantage with lagged copies. As admin need to do lot of manual work. I heard few changes in Exchange 2013 related to lagged copies. However, that is also not enough. I personally prefer backup over a lagged copies.