We currently do a D3 backup each night at 3:00AM to a virtual tape file,
then the file is verified. We ultimately end up with a file named "FILE-SAVE
YYYY-MM-DD.d3p". Saves going back several weeks are kept available on-line
(dailies are kept for two weeks, weeklies longer). About once a month, I
will also take a weekly file-save and burn it to a DVD so I have a permanent
archive.

Each morning, the D3 (Windows) server is backed up to a DLT tape using the
lame Windows backup utility. The backup tape is verified, moved offsite,
stored vertically, kept away from nuclear reactors, and saved for several
weeks before reuse. So, I have several weeks of duplicate verified backups
spread across many tapes.

Are there any issues with this backup strategy, vs. doing the D3 backup
directly to tape? Thanks.

Brian Bond wrote
1) Embellish your backup media with a handwritten admin log of the clues
you'll need to use them in future years; a) DM account password,
b) what version of D3/NT you've got running, c) frame size
c) D3 system id {you have to go to the console and grab a mouse to read
this, unlike d3/linux releases -- grrr!!! } Oh, and go make an 'ark'
file in
dm today -- copy your mds account qpointers into it, or write them in
your paper log.
2) compress those backup files on disk; expect about 4:1 resulting size
3) If they compress enough, to fit on a single cdrom, prefer that to dvd;
the media is cheaper and you can go steal the drive out of Timmie's PC
if your server drive packs up the day you need to do a restore.
4) use the LAN to make a gratuitous copy of the most recent backup to
whatever pc will contain it. We have about a 1 gig database, and get
5:1 compression, so it takes less than a minute to copy the backup to
my PC each day. I launch the batch file for this from an icon on my
desktop.

I was compressing the archives onto CD, but I discovered that at times the
compressed file-save would not uncompress (the zip file would have some sort
of problem with it, as reported by PkZip.). This happened whether the file
had been copied from a different server, or read from a CD. Really wierd.
Given how cheap DVD media has become, I just bagged compressing the file.


"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote

Brian Bond wrote:
Could any of the individual files have been over 2 gigabytes? I ran a
test awhile ago indicating that Zip works with 2GB+ total input data,
but not with 2GB+ .zip file; it might also fail with a 2GB+ individual
input file?

Makes sense.

--
"Always look on the bright side of life."
To reply by email, replace no.spam with my last name.

On Fri, 15 Jul 2005 11:55:24 -0700, "Brian Bond"
<brian (AT) XYZXYZXYZXYZbonanzapress (DOT) com> wrote:

We've had pretty poor luck with our customers doing this (or using third-party
backup programs like Veritas instead of the Windows backup). I don't really
know why; there wouldn't seem to be any good reason it wouldn't work. But
that's our experience.

I do like Frank's suggestion of copying the backup file to another machine.
We do that in-house. It makes for a nice alternative if the usual medium
(tape, CD, DVD, whatever) should ever have a problem. You wouldn't have to go
a day or three without a backup if that's how long it took to fix the medium.
---
Rod
Email address altered to deter spam.

We have just replaced our tape backup regime with one that uses UDB
HDD's instead, mainly because we started to overflow the old 20/40Gb
DDS 4 tapes. backups are done to file system, which is then copied
"elsewhere", including onto an 80Gb 2.5" USB 2.0 HDD --> a little bit
"bigger" than a tape (capacity & size), but certainly a cheaper option
than buying a new SCSI tape sub-system