Initialization of a transactional replication subscriber is a highly valuable tool. For very large databases (VLDBs), snapshot generation and application can have a considerable performance impact and take a long time. Consequently, initializing a subscription from a snapshot can be prohibitive.

The next logical step in the evolution of replication was to make better use of the backups that were already being applied to the subscribers. Initialization from backup was designed to alleviate some of the problems faced by administrators of VLDBs. However, there are perceived limitations and restrictions regarding initialization from backup for transactional replication, but those are not insurmountable barriers to using this process. You can still use initialization from backup with a little creativity and by utilizing log or filegroup backups.

The reasons often given for not using initialization from backup include a need to use a third-party compression for full backups, especially as a tool for encryption or to gain maximum compression ratios; a belief that the subscriber must be initialized from a full backup; and a requirement to limit subscribers to a subset of tables. All of these limitations are easy to handle with initialization from backup.

This whitepaper provides clear guidance on the perceived limitations and restrictions on initializing transactional replication subscribers from a backup. The whitepaper describes the trouble with snapshot initialization, which backups are suitable for initialization, moving beyond simple initialization from backup, and initializing from a filegroup backup

Register to read the full whitepaper.

Topics: Database Backup
Products: SQL Safe Backup