Date: Wed, 4 Mar 1998 11:20:03 -0500 From: sbabkin@dcn.att.com To: karl@mcs.net, shimon@simon-shapiro.org Cc: grog@lemis.com, hackers@FreeBSD.ORG, blkirk@float.eli.net, jdn@acp.qiv.com, tlambert@primenet.com, wilko@yedi.iaf.nl Subject: RE: SCSI Bus redundancy... Message-ID: <C50B6FBA632FD111AF0F0000C0AD71EE4132D3@dcn71.dcn.att.com>
next in thread | raw e-mail | index | archive | help
> ---------- > From: Simon Shapiro[SMTP:shimon@simon-shapiro.org] > > > > The problem isn't even necessarily the data loss - its the restore > time. > > A > > 9G drive takes a shitload of time to reload from even the fastest > DLT > > drive. > > > > We still run tapes nightly for incrementals, and weekly for full > dumps - > > but > > they are more for the "aw shit" user-induced stupidity (like the > infamous > > "rm -rf *") rather than hardware coverage. The pain of a restore > across > > disks of this size is just too darn big. > > I wrote a white paper at Oracle some years ago, claiming that > databases > over a certain size simply cannot be backed up. I became very > UN-popular > very quickly. In you moderate setup, you already see the proof of > corectness. > IMHO they CAN be backed up. As long as you have enough spare equipment. At my previous work in bank where we were paranoid about backup and downtime I think I have found a scaleable way of doing so. We used it on a relatively small database (~15G) but I can't see why it can not be scaled. First, forget about exports. Copy the database files and archived logs. Additionally to the production instance have two more instances. One gets archived logs copied and rolled forward immediately. Another one gets archived logs copied immediately, but rolled forward only after they aged. Copy this third instance to tapes time to time. Copy archived logs to tape as fast as they get produced. If the production instance crashes, use the second one. If someone removed a table and that was more recently than the age of third instance, start this instance and get this table from it. If this removal was noticed too late, there will be big PITA with restoring from tapes. Do offline (better but with downtime) or online backup if you do reset logs. This can be done fast if the I/O subsystem is has enough throughput to copy all the disks of database to backup disks in parallel, and if the disks can be remapped between machines easily. For 4G disks this will be not more than 1 hour. > This is why most MIS types shiver when they hear about databases on > Unix > filesystems. All you need is a crash and fsck in a bad mood. If you > are > Nope. Databases must have dedicated filesystems. And as long there are no files created or removed in these filesystems or blocks added or removed to/from any files in them (in other words, no change of metadata, what is normal for databases) there is no chance that you will lose your database. I know that not everyone follows this rule (looks like everyone in AT&T does not do it) but this is their personal problem and not the problem of Unix. > lucky, the entire data base is gone. If you are unlucky, a block will > disappear form somewhere in the middle, and you will find out a week > later. > Now backup is literally useless. > -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C50B6FBA632FD111AF0F0000C0AD71EE4132D3>