Re: Handling of archive logs

70% of your backups are not useable?!?!?!?! Why back up your system then? I'll agree that backups can become invalid for a variety of reasons. But I would never put up with a backup strategy that only lets me recover 30% of my backups.

Just my 3.14159265 cents worth,
Brian

Syltrem wrote:
>
> This is the 70% - 30% rule of backups.
>
> 70% of them can not be used for whatever reason:
> Tape has bad blocks on it, tape marker fell off, tape unit broke on the day
> you need it, tape was lost, or more often (and sad) the data is readable but
> unusable because of blocks inconsistancy in the file (due to bad method of
> backing up or users access to file during backup).
>
> That's the way it is.
> Syltrem
>
> <oratune_at_aol.com> wrote in message news:8t2bja$nqd$1_at_nnrp1.deja.com...
> > In article <39F4826C.43E02426_at_home.nl>,
> > frank <fbortel_at_home.nl> wrote:
> > > Budgets are tight - as ever.
> > > Sites I have worked tend to have 1 or two days of uncompressed
 archived
> > > log files, and ditto compressed - thus having at least 2 copies on
 disk, and
> > > on 2 different tapes. Murphy, huh? Murphy was an optimist.
> > >
> > > Or -as one of the guys put it- tapes? a tape is just rust on wheels!
> > > And, indeed, I have witnessed the chaos when backups cannot be
> > > read from tape... But then again, no disaster plan testing...
> > >
> > > Frank
> > >
> > > "Howard J. Rogers" wrote:
> > >
> > > > The realist in me says if you think you can get away with it, why
 not?
> > > >
> > > > The purist in me says... the archive logs are the only thing
 standing
> > > > between you and data loss, so you play around with them at your
 peril.
> > > > Compression to me sounds like a very *bad* idea, since you are
 rather
> > > > relying on the compression working correctly, and the decompression
 to work
> > > > without a hitch when needed. Anything goes wrong at either end,
 and you've
> > > > just lost your logs, and hence the data they were supposed to be
 protecting.
> > > >
> > > > Managerially, it's also suspect: when the database goes down, your
 job is
> > > > supposed to be to get it back up and running again as quickly as
 humanly
> > > > possible. By compressing your logs, however, you've introduced
 another
> > > > stage in the process, and hence meantime to recover will inevitably
 be
> > > > longer.
> > > >
> > > > My suggestion? Buy some more hard disks.
> > > >
> > > > Regards
> > > > HJR
> > > >
> > > > "Stefan Fournier" <Stefan.Fournier_at_gmx.de> wrote in message
> > > > news:8FD3C9489StefanFourniergmxde_at_130.133.1.4...
> > > > > Hello,
> > > > >
> > > > > I have a question around the handling of archived logs and would
> > > > > like to hear how you do it.
> > > > > Today we did a import of a schema with about 500 MB. While the
 import
> > > > > ran, the database wrote so many archived logs that the filesystem
 went
> > > > > full.
> > > > > I then gzipped the archive logs to release diskspace and the thing
> > > > > finished ok.
> > > > > My idea now is to create a cronjob which zips new archive logs
> > > > > every 15 minutes or so.
> > > > > Is that reasonable?
> > > > >
> > > > > Thanks for any input.
> > > > >
> > > > > Regards,
> > > > > Stefan
> > > > >
> > > > >
> > > > > --
> > > > > Stefan.Fournier_at_gmx.de
> > >
> > >
> >
> > This is quite true. I don't know how often I have tried to impress
> > upon the on-site DBA and System Administrator to read-verify the backup
> > tape prior to accepting it as valid. Simply because it "wrote" means
> > absolutely nothing, as a successful write only indicates that the
> > device was functioning properly. Read-verifying the backup tape
> > ensures that the tape is usable (at least at the time the backup is
> > created -- I won't go into the hazards and pitfalls of improper tape
> > storage). I have seen many "backups" end up in the trash when the tape
> > cannot be read at the crucial moment of recovery.
> >
> > --
> > David Fitzjarrell
> > Oracle Certified DBA
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
 

-- 
========================================
Brian Peasland
Raytheons Systems at
  USGS EROS Data Center
These opinions are my own and do not
necessarily reflect the opinions of my 
company!
========================================