Backup of SAN databases

I'm looking for some "best practices" help from the SAN gurus out there.
We're looking to move some of our databases to an EMC SAN. Currently we run
full backups every night and tran logs every 15 minutes, which are then used
by logshipping to restore to warm standby servers.
After moving to the SAN and a clustered environment, the logshipping system
will be dropped. Since the only other reason for backups is DR, there's some
dispute as to whether SQL backups will even be necessary going forward.
We're being told that the SnapView software we're getting with the SAN will
be able to create clones of the production LUNs, from which we can then back
up to tape or restore back to live if/when necessary.
As a long-time DBA it goes against my grain to turn off SQL backups and put
the databases in simple recovery mode <g>. Is that generally how things are
done on a SAN? I should add that I fully understand the "point-in-time"
issue, that is if we take a new clone every night of the live LUNs we may
lose up to 24 hours of transactions if we have to re-sync back. Other than
this issue, are there good or bad sides to SnapView as our primary SQL
backup strategy?
Thanks
Randy Rabin
Hi
No, no, no.
We have a massive SAN environment comprising of EMC and Hitachi, and even
though we use EMC's SRDF to have data moved to DR in real time, we still do
Full backups daily and Log dumps every 15 minutes. I trust EMC to store the
data, but once EMC wants to be the only form of backup I have, I start to
worry. The also have bugs. SnapView and SRDF will faithfully transfer the
corruption that your DB could have to the backup copy as it knows no better.
If you run simple recovery mode, how can you do point in time restores? Most
DB outages are caused by human error like dropping tables, or deleting too
many rows from a table. What it an application error destroys data and then
you get asked, we need a restore up to 10:28 this morning?
Clones of LUNs are not feasible to be run every 15 minutes. Put the dumps on
different LUNS to the data and log. Even an EMC engineer can mess up a
configuration and then you have no good backup.
A SAN is a storage mechanism and not a replacement for good backups.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Randy Rabin" <randyr@.channeladvisor.com> wrote in message
news:e2B9Pp$WFHA.2080@.TK2MSFTNGP15.phx.gbl...
> I'm looking for some "best practices" help from the SAN gurus out there.
> We're looking to move some of our databases to an EMC SAN. Currently we
> run
> full backups every night and tran logs every 15 minutes, which are then
> used
> by logshipping to restore to warm standby servers.
> After moving to the SAN and a clustered environment, the logshipping
> system
> will be dropped. Since the only other reason for backups is DR, there's
> some
> dispute as to whether SQL backups will even be necessary going forward.
> We're being told that the SnapView software we're getting with the SAN
> will
> be able to create clones of the production LUNs, from which we can then
> back
> up to tape or restore back to live if/when necessary.
> As a long-time DBA it goes against my grain to turn off SQL backups and
> put
> the databases in simple recovery mode <g>. Is that generally how things
> are
> done on a SAN? I should add that I fully understand the "point-in-time"
> issue, that is if we take a new clone every night of the live LUNs we may
> lose up to 24 hours of transactions if we have to re-sync back. Other than
> this issue, are there good or bad sides to SnapView as our primary SQL
> backup strategy?
> Thanks
> Randy Rabin
>