Comments on: Are Lagged Database Copies a Waste of Time?

By: JW

JW — Sun, 14 Nov 2021 15:51:08 +0000

In reply to Christian Gastl. Why would you want to restore a lagged db for a few users that deleted something? The restore affects everyone.

By: Captain Haddock

Captain Haddock — Mon, 20 Jan 2020 18:50:21 +0000

In reply to Seth. Ransomware rendered your thinking obsolete!

By: David Wilhoit

David Wilhoit — Mon, 26 Sep 2016 10:57:29 +0000

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.

By: mohammed kabir

mohammed kabir — Thu, 26 Mar 2015 20:30:14 +0000

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.

By: Jeremy Bradshaw

Jeremy Bradshaw — Fri, 13 Feb 2015 02:17:23 +0000

In reply to Seth.

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…

By: Seth

Seth — Thu, 12 Feb 2015 22:43:49 +0000

In reply to Jeremy Bradshaw. Hi Jeremy, What is your setup for Exchange Native Data Protection? What are your time thresholds? What do you use for monitoring?

By: Jeremy Bradshaw

Jeremy Bradshaw — Thu, 12 Feb 2015 16:02:37 +0000

In reply to M.

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.

By: Jeremy

Jeremy — Tue, 16 Dec 2014 13:37:28 +0000

In reply to Seth. I am jealous of you and your company:).

By: Seth

Seth — Wed, 19 Nov 2014 16:46:37 +0000

In reply to Stewart Jump. 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.

By: Ed Kummel

Ed Kummel — Tue, 18 Nov 2014 21:21:32 +0000

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!