• Which database and log files are being replicated?

    Was the replication up to date on all of them, or was it behind on some of the LUNs?

    In our testing, we put every .mdf and .ldf except for tempdb on to SAN luns - including master, model, and msdb.

    We carefully set up SQL Server on the DR site to point to where those would be mounted, and left SQL shut down on the DR side.

    Thus, we first mount with Recoverpoint and make sure the LUNs are attached, online the LUNs, rescan them, make sure the drive letters are what's expected and are all presenting, and only then do we try starting SQL Server.

    It's a little more complex than that, but that's the basics. It's critical to make sure every drive is mounted properly and is available at the expected drive letter before starting SQL Server.

    ETA: Using the above technique, there's no reason whatsoever to detach or attach databases within SQL Server; they come as a complete set, from Master on down (except TempDB, which you simply need to have storage at the correct drive letter/mount point for). Remember, RecoverPoint is a very simplistic block level replication; it knows nothing about databases, nothing about files, not even anything about file systems.