Hi

This is quite tricky. Here is some reasons why.

Assume the setup, Server Pub (publisher), sub (subscriber) and dist (remote distribution) and DR Dist for the DR distribution

If you backup your distribution database , you can restore it to the same instance and aside from a break in the connection and potential missing transactions you will be fine, you can be more fine depending on your retention (i.e. making sure you have data between backup and cleanup from the cleanup agents). You can also be in a better place when you run sync with backup. In this case the data on the publisher will stay in the publisher log untill backed up, thus is you distribution database fails you the missing commands between point of failure and the distribution backup will be re delivered by the log reader, very awesome.

If you restore this backup of the Dist to to DR Dist server you have several issues.

1 - once it's restored it's user database. This is one of the reasons why you need to restore the master also.

2 - if it's remote distribution the your replication jobs, agents log and distribution and cleanups reside on this same instance and this is where the MSDB comes in, so that you can have the jobs on your DR instance you also need to restore this database.

In my opinion there are easier ways for ensuring Replication DR.

1 - sync with backup on publisher but the trade off is bigger logs. Depending on the frequency of your distribution backups.

2 - use a long retention period on your distributor , this will ensure commands is available when the subscriber fails and is restored from a backup.

You need to determine the point of failure you want to cover. I have always argued that distribution is a "system" db. Store and forward. The leaner the meaner. this reduce complexity for distribution DR. However you need to ensure you subscriber is covered.

The publisher database is assumed to be covered because 1, if it's worth replicating it should probably get full backups now and then and log backups. When these are restored it will ensure replication continuation.

If this doesn't answer your question it's perhaps worth to be slightly more specific on the area you wish to guard yourself against failure such as pub, dist or sub. List your recovery models on all of those and also the retention and how each of them are currently being backed up. Are you trying to guard against physical failure of hardware, potential software issues, IO protection etc.

Hope this helps.

Cheers

Jannie