SAN Replication and SQL Server 2008 R2

dajonx,

Yes, you can clone a replica to create a new volume on the secondary group. The new volume contains the same data that existed at the time you created the replica; initiators can connect to it in the usual way. Cloning a replica has no impact on the original volume and the replication configuration. If the original volume is still available, replication can continue, as usual.  Ensure you have enough free space available on the DR PS Array group cloning a replica volume.

Regards,

Joe

Dajonx,

There are a couple things that can be done. Your way is possible, but there are faster options.

Such as you can take a snapshot of the SAN and then go to another host and load the snapshot for backup. Or you can go to support.equallogic.com/support and then click on Back Up Solutions for other methods, that may work a bit better for you.

The Replication is a consistent backup, but it takes a lot longer to perform than some of the others.

Thank you very much!  

Chris; I was not able to locate the "Back Up Solutions" on the Support page.  Can you please link to that page?

I have attempted to mount a snapshot on the DR SAN from the Primary SAN which worked.  When I tried to attach the database to SQL Server, it said:

CREATE FILE encountered operating system error 5(Access is denied) while attempting to open or create the physical file 'F:\SQL Data\Database.MDF'. (Microsoft SQL Server, Error: 5123)

What am I doing wrong here?

I have initially tried attaching the database using the SSMS GUI.  When I tried attaching the database using T-SQL, the error message is:

Unable to open the physical file "F:\SQL Data\Database.MDF".  Operating system error 5: "5(Access is denied.)".

Hmm...  When I tried cloning, I was unable to attach the database and getting the same error message...

Ensure you cloned the inbound replica volume by follow these procedure:

psonlinehelp.equallogic.com/.../groupmanager.htm - select Replication Tasks> Cloning an Inbound Replica.

Then,  take a look in the server event log, or the sql event log, what event did you see when the database tried to attach, and see what it says.

Joe

I have figured out that you must open SSMS as "Run As Administrator" to bypass the "Access is denied" error message.

However, I still cannot attach the database.  The error message now is "Could not open new database 'Database_TEST'. CREATE DATABASE is aborted. (Microsoft SQL Server, Error: 1813)"

In the Application Logs, I have four error messages:

1) fcb::close-flush: Operating system error (null) encountered.

2) FCB::ZeroFile(), GetOverLappedResult(): Operating system error 19(The media is write protected.) encountered.

3) FixupTail: Operating system error 19(The media is write protected.) encountered.

4) Starting up database 'Database_TEST'.

Do you know how to resolve these issues?

dajonx,

In the group manager, highlight the clone volume, look in the top block titled "General Volume Information" on the line "Access Type" it should read "read-right, not shared" (if this is not a clustered server).  Change this to not shared if it is set to shared.  Also within the windows os, review the permissions to the volume root, and subdirectories for the database you may need to reassign the AD rights).

Post anything else you find.

Regards,

Joe

Could this be the resolution?

support.microsoft.com/.../971436

My current SAN Policy is: Offline Shared

I do a "detail disk" on DISKPART and the Read-Only is set to No.  Yet the clone is still write-protected.  Any ideas?

I did not reboot the server.  Perhaps if you change the other attributes other than readonly?

Also, After you change these values, Microsoft recommends that you reboot the server. However, it is usually sufficient to logout from the iSCSI target (in the initiator) and log back in, to get the system to eject and reinsert the disk device