NO MORE UPDATES TO THIS PAGE PLEASE. SUBMIT ALL FUTURE COMMENTS TO

footnote pg 446

How is this legal requirement changed by SOX ? A large section on how SOX impacts requirements could be useful.

21.1.2 pgs 449->453

I think some extra emphasis that the assumptions made in your examples aren't necessarily real world. Indeed the 20%/day isn't doesn't match my real-world experiences at all. If people work on a file one day then they stand a good chance of working on it the next. I've also found user work is far far outstripped by two main system processes; log files (eg apache logs or mail logs or...) and mail files. A 10Kb addition to a 1.5Gb file will cause that whole 1.5Gb to be backed up on the incremental. Bleh bleh bleh.

pg 454

Incremental restores have another issue. To restore fully you need to restore the level 0 and then incremental(s). This can result in files that were previously deleted being restored (level 0 taken, file deleted, level 1 taken disk explodes, new disk, level 0 restored, level 1 restored... the file that was deleted at step 2 is now back). In some cases this could result in the restore not being able to fit onto the disk!

21.1.4 pg 456

I don't see any costs for replacement of old/damaged media, or for planned obscelence and replacement.

21.2.2. pg 466

Offsite storage of tapes - see the earlier anecdote I mentioned in the DR chapter of using DR sites to backup the production site, therefore tapes are automatically offsite and readily available in case of DR.

21.2.2 pg 467

Your anecdote of using the network to backup... how about using Usenet posts to backup your data?

-- StephenHarris - 22 Aug 2006

21.2.3 pg 467

Oh my! As an ex-DBA... shudder. I have a mantra; "The right tool for the job." That might mean Windows, it might mean MacOS^?, it might mean Unix. Whilst I have my preferences, I don't let that dictate my solution. Now if you're talking about a 24x7 database then if the best your DBMS can do is shutdown/split mirror/startup to keep downtime to a minimum then you (well the DBA) has selected the wrong database. Shutting down the database may have consequences (eg a web site using mod_perl and with persistent DBMS connections may need to be restarted after a DBMS shutdown). Oracle, for example, has the idea of putting tablespaces into "backup" mode. Essentially more data is written to the redo/archive logs to allow recovery (if needed) and it's guaranteed that the datafile will be consistent during that phase. So the way to back this up would be to put the tablespaces into backup mode, split the (3-way) mirror, take the tablespaces out of backup mode and then backup the offline mirror-fragment. Full 24x7 operation, no shutdown, approved solution by DBMS vendor.

Fortunately, as SAs, we don't decide on how to backup the DBMS; that's the DBA problem. Hopefully they've selected the right tool for the job!

21.2.4 pg 468

The leapfrogging of disk/tape isn't something a large site can afford. With the expense of installing large-scale backup solutions (robots, many thousands of tapes etc) it's not feasible to revamp the backup solution every 4 years. At $5000 per drive (Quantum DLT-S4) for a standalone drive, we're talking 6 digit budgets for a large site! It's also questionable whether tape technology is keeping up with disks. SDLT can do 1.5Tbyte (compressed). Just how much data is there in a SAN array, or NAS? Just one of my servers loads 1.2Tb of data for its own private use from NAS devices with almost complete data change over the course of 30 days. If you roll out 1000 Linux blades, each with 36Gb disks on them then you potentially have to backup a potential 36Tbytes of data (one of many reasons I dislike blades with local hard disks).

9 inch anecdote pg 468

Old technology could also be stored at a DR location. Remember to test it regularly so you know it works when you really really need it!

-- StephenHarris - 23 Aug 2006