Activity overview
Latest activity by David Richard
That’s an interesting situation. When working with SQL 2008R2 transactional replication, the replication agent doesn’t actually take its own transaction log backups—it just reads the transaction log entries. You can still configure RedGate to run your full backups and transaction log backups without interfering with replication. The key is to ensure the log backups are consistent and not truncated by multiple processes. One approach would be:
Let RedGate handle both full and log backups, since it fully supports replication scenarios.
Ensure your log backup schedule aligns with your recovery objectives (e.g., every hour).
Test the restore sequence (full + logs) in a dev environment to confirm replication isn’t impacted.
I’ve seen a similar integration in an Education App Development Company project where large student databases were replicated for analytics and reporting. They successfully used RedGate for both full and log backups while keeping replication intact. So yes—you don’t have to split duties between native SQL and RedGate. It’s cleaner to let one tool (RedGate) manage all backups, provided you monitor and validate restore paths. / comments
That’s an interesting situation. When working with SQL 2008R2 transactional replication, the replication agent doesn’t actually take its own transaction log backups—it just reads the transaction lo...