Indianrock (8/15/2012)
My impression was that backups done via Netapp's snap manager for sql could be done very often, very fast and that for databases in full recovery, its an either or proposition -- you can't back these databases up with native sql because you'll break the netapp log chain.One thing we haven't tested is the IO freeze time. One of our data files in in line to be split up, but currently that one is 1.1TB. You also have to make sure backups run with sql snap manager don't step on eachother -- can't have a log backup overlap a full backup etc.
Add in the possibility that the database might be migrated off of Netapp in a year or two and its quite an investment to go that route now.
I don't understand how this relates to your original question. However, you can use native backups with no problem as long as you use the COPY_ONLY parameter.
The reason Snap Manager backups are so fast, is because they are not 'backing' up the database. They are taking a snapshot of the LUN where the database files are located. This is why you cannot put the system databases on the same LUN as the data files - and why they also recommend having a separate LUN for the data file.
If you have multiple data files on a single LUN - then all of those databases are 'backed' up at the same time. This causes issues if you want to be able to restore one of the databases - because then you cannot restore the LUN to the snapshot and instead have to present the LUN as a new LUN and use native restore on the single database.
How this all relates to using the Snap backups for DR is simple. You cannot do that without copying the full database across the wire - every time. You cannot copy the snapshot - because the snapshot has to be able to read the data from the source system.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs