Think of RecoverPoint's presented LUNs as a removeable platter or floppy or USB thumb drive or USB/Firewire/eSATA external drive - whatever you're comfortable with. It's storage that you assign a drive letter to.

Think of the drives/virtual disks/partitions/logical drives/etc. on your system the same way - it's harder to move them, but they're still storage you assign a drive letter to.

Think of SQL as something that just looks for drive letters - it really doesn't care what storage is attached, it's going to blindly look for what it expects.

First SQL looks for the Master database and the ERRORLOG file - that's why those command line parameters are set in SQL Server Configuration Manager, under the properties of the service, Advanced tab.

Then SQL reads from the Master database to find everything else.

Thus, the trick with Recoverpoint is, ideally, to have 100% identical drive letters and paths for all .mdf and .ldf files on Primary and DR (including tempdb! We just don't both replicating it, since it's "fresh" on each startup) before we start SQL Services.

Realize that you can always change drive letter assignments in diskmgmt.msc!

X: is whatever drive letter and path your production database has its system database datafiles (and maybe the logs)

Y: is whatever drive letter and path your production database has its system database logs (if they're in a different location from the datafiles)

A: is some unused letter on DR

B: is some other unused letter on DR (if Y: is in use)

So, what you do (OPTIONAL separation of Master log and database files, X: for data and possible logs, Y: for possible logs) [EXAMPLE NOT TO SCALE - this is pseudocode]:

1) Take some local or external storage, and assign it to X: (and Y:), where your Master database (and Master log) will go.

2) You install SQL such that your system DB's are on X: (and their logs on Y:).

2a) Alternately, move your system DB's to X: (and their logs to Y:) using the normal methods for moving system DB's.

2b) make sure ERRORLOG is on the same drive letter and path on Primary and DR, too; replicate or not at your option (I would, to track errors that happened during or prior to disasters!).

3) That's your "local install" - useful for doing patching, trivial function checks, and so on.

4) Stop SQL on DR

5) Now, change X: to A:, and if need be, Y: to B:, by changing the drive letter

6) Mount Recoverpoint LUNs from primary to DR, making sure on DR they get the same drive letters.

7) Start SQL (NOTE: the fine details may not be quite right, particularly the order - if anyone knows the internals and would like to correct this, that would be great! The general process, however, must look a lot like this)

7a) SQL looks for ERRORLOG, and finds it where it expects, because both Primary and DR are set up with identical paths and filenames ERRORLOG

7b) SQL looks for Master on X:

7c) SQL finds Master where it expects, because both Primary and DR are set up with identical paths and filenames for Master .mdf and .ldf files

7d) SQL reads Master to see where other databases are

7e) SQL starts tempdb in the path specified; which is can, since that path exists on both Primary and DR

7f) SQL looks for other database locations from Master

7g) SQL finds the other databases where it expects, because both Primary and DR are set up with identical paths and filenames for other database.mdf and .ldf files!

WARNING: ALL YOUR JOBS ARE PRESENT AND READY!!! ALL YOUR LINKED SERVERS ARE PRESENT AND READY!!! DO NOT START SQL SERVER AGENT UNLESS YOU REALLY, REALLY NEED TO!!!! If you start SQL Server Agent right off, then if you have a job that does production work like outputting a file or deleting backups or sending an email to a client, it's going to try to do that, because it thinks it is production!!! This could be a serious, serious problem if you're running tests!