Craig,

No, we don't use the SAN to avoid standard database backups using SQL Server. We do both SAN replays and SQL Server backups for the purpose of intentional redundancy, in case one fails. Plus, sometimes it's easier and quicker to restore the backup of a small database using SQL Server, so there's the issue of convenience, as well.

We take simple replays (snapshots, what Compellent calls Instant Replays) of the database backup files, the .bak files. The reason is that Compellent says Replays improve the performance of the automated data migration from Tier 1 storage (15K FC) to Tier 3 storage (SATA).

Currently, and this is soon to change:

1. We are taking a Replay Manager snapshot every 24 hours. We are soon going to experiment with increasing the frequency of these to see how much additional space they require. We will probably start out conservatively, say every 4 or 6 hours, and shrink that window until it reaches a point of diminishing returns by consuming too much disk space.

2. We take SQL Server generated full backups once every 24 hours.

3. We take SQL Server generated differential backups every 30 minutes, except when the full backups are in progress.

We decided not to implement point-in-time recovery. Business requirements dictated that being up and online was more important than some data loss, so we use the Simple Recovery model in SQL Server.

I was as skeptical as you about the synchronization of the .mdf and .ldf files during a SAN replay (snapshot). Compellent assures their customers that as long as they use the Replay Manager software (which utilizes the Microsoft VSS technology) to coalesce the 2 files, there will never be any data errors. We've experimented with it to the point that we believe Compellent and are comfortable with it.

LC