Backup SQL2000 on EMC

Hi all,
one of my customers is going to use SQL2000 on existing EMC Clariion 4700.
They're using EMC SnapView for filesystem backup together with Veritas
NetBackup.
They won't use the SQL Integration Modules for SnapView so there is the
question of backing up the databases. Is there any other way to backup the
databases while using the SnapView functionality - and keeping SQL2000
services running?
Any help would be appreciated...
Wolfgang
"wso" <wso@.discussions.microsoft.com> wrote in message
news:748B28E5-9172-4AAB-877B-195AB1EFC035@.microsoft.com...
> Hi all,
> one of my customers is going to use SQL2000 on existing EMC Clariion 4700.
> They're using EMC SnapView for filesystem backup together with Veritas
> NetBackup.
> They won't use the SQL Integration Modules for SnapView so there is the
> question of backing up the databases. Is there any other way to backup the
> databases while using the SnapView functionality - and keeping SQL2000
> services running?
> Any help would be appreciated...
> Wolfgang
The data and log files are kept open and active while SQL Server is running.
I am assuming that Snap View won't touch them in this state.
The quick and easy solution is to schedule a regular SQL Server job to
perform SQL based backups to disk. Once the backup is complete, the backup
files are closed and Snap View can collect them (or Veritas for that
matter).
It's sort of doing double duty, but it does give you some flexibility.
Rick Sawtell
MCT, MCSD, MCDBA
|||Your only problem is that you might get torn pages and/or log file
fragments, especially if you are storing data and logs on different LUNS
mapped to different physical disks. I suggest testing the backups heavily,
especially where you take backups under heavy load. I suspect that there
will be a fairly high failure rate. They may have this feature now, but
when I was looking, they couldn't synchronize multiple LUNs for a snapshot,
thus rendering the backups unreliable.
I don't even bother with Snapview. I do SQL-level backups to a separate
network file share (non-SAN based) and then spin those to tape to get an
archive history. The extra storage is far cheaper than the Snapview license
for a large SAN.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"wso" <wso@.discussions.microsoft.com> wrote in message
news:748B28E5-9172-4AAB-877B-195AB1EFC035@.microsoft.com...
> Hi all,
> one of my customers is going to use SQL2000 on existing EMC Clariion 4700.
> They're using EMC SnapView for filesystem backup together with Veritas
> NetBackup.
> They won't use the SQL Integration Modules for SnapView so there is the
> question of backing up the databases. Is there any other way to backup the
> databases while using the SnapView functionality - and keeping SQL2000
> services running?
> Any help would be appreciated...
> Wolfgang
|||Hello Geoff,
I was wondering if you can help me with the SAN/SQL Cluster backup question?
We have 3-Node (2 Virtual Instances with Standby) Cluster and one dedicated
LUN (Raid 5) for online backup.
Question1:
I think we need to expose the BACKUP LUN to each HOSTS? so SQL server backup
job can backup database on that LUN
Question2:
Once we expose that LUN to SQL CLuster Nodes the HOST will have full control
and how the backup wil work on second virtual host?
May be you can tell me what is the BEST practices of SAN/SQL Server backup
solutions. Just so you know we are trying to AVOID using the LAN (performance
etc.) and thereofore will also have dedicated backup server for TAPE backup...
Thanks.
Kamal Hassan
"Geoff N. Hiten" wrote:

> Your only problem is that you might get torn pages and/or log file
> fragments, especially if you are storing data and logs on different LUNS
> mapped to different physical disks. I suggest testing the backups heavily,
> especially where you take backups under heavy load. I suspect that there
> will be a fairly high failure rate. They may have this feature now, but
> when I was looking, they couldn't synchronize multiple LUNs for a snapshot,
> thus rendering the backups unreliable.
> I don't even bother with Snapview. I do SQL-level backups to a separate
> network file share (non-SAN based) and then spin those to tape to get an
> archive history. The extra storage is far cheaper than the Snapview license
> for a large SAN.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "wso" <wso@.discussions.microsoft.com> wrote in message
> news:748B28E5-9172-4AAB-877B-195AB1EFC035@.microsoft.com...
>
>