Date: Mon, 27 Oct 2003 10:09:06 -0500 From: Bill Vermillion <bv@wjv.com> To: "Dave [Hawk-Systems]" <dave@hawk-systems.com> Cc: freebsd-isp@freebsd.org Subject: Re: restoring dumps from crashed drive Message-ID: <20031027150906.GA36540@wjv.com> In-Reply-To: <DBEIKNMKGOBGNDHAAKGNGEEIGFAC.dave@hawk-systems.com> References: <20031027134939.GA35680@wjv.com> <DBEIKNMKGOBGNDHAAKGNGEEIGFAC.dave@hawk-systems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 27, 2003 at 09:41 , Dave [Hawk-Systems] showing utter disregard for spell-checkers gave us this: > >Coming from commercail Unix systems I've never been a large > >fan of dump restore but having my clients use commercial > >super-tar programs [called that because they handle devs, and > >things that used to faily] that also have full verify restore too. > I am gettin gthe impression that dump is more of a file > archiver rather than a true system backup utility. Dump is ancient - and while touted as a backup many wont trust it. Note the BUGS section of the FreeBSD man page. "Fewer than 32 read errors on the file system are ignored". That bothers me because I'm of the mind set you show know every error and the make a determination whether they are important or safely ignore. > >On the machine as the IPS [a colo facility] I use rsync to backup > >the important data and var to get the database. But I never get > >about 2 OS revs behind so I haven't had the problem you expressed. > a noted shortcoming on our part. it wasn't broken so we didn't > try to fix (aside from a few patches), which evidently came > back to haunt us when a repair of this magnitute was required. You can't be blamed for that. Many people do consider dump broken, and that's why alternatives emereged. I'm probalby more aware of things like this as being an SA for hire for small businesses and have been around several differing Unix systems. > >I got spoiled about 1990 using a program from alt souces that > >did bit level verifies and then the commercial programs started > >using that. I've seen more than one instance where backups > >wouldn't restore because the backup failed for some reason or > >other. None of that helps you now, but I'd strongly recommend > >a program like that as you can put everything back just the way it > >was - until you get to the point where new hardware makes a > >complete identical restore impossible - eg new controllers, NICs, > >etc. > The dissapointment (or misunderstanding on my part of what > dump/restore could handle) is that the hardware was identical, > including the new hard drive make/model. Absolutely nothing had > changed, it just didn't seem up to the task of restoring over a > basic file system. The one thing you did not know was that the tape backup [I'm assuming tape] was completely successful. If tape and you ran a typical verify on the tape afterward - all that basically does [or did on the one I'm used to] was to verify the checksums on the headers. But if data was mis-read from the HD or it got corrupted in transit from the HD to the electronics on the tape drive, the bad data will be written and a checksum for that will added to the end of the block, and you will wrongly assume that the data is OK as the checksum matched. That's why I started using bit-level verifies. And that was from about 1990 where many small systems still backed up to floppies. I go far enough back with these wee beasts to remember that HW wasn't as reliable as it is now. Today's HW often gives a false sense of security as it fails so often. > one of those "never know if it works untill you have a > onedisaster"... well we had , and it didn't. Well you are luckier than those who had a disaster and then couldn't survive the data loss. I had one client whom I could NOT get to take tapes off site - figuring they were safe in his office. One day after a pretty bad experience with lightning, losing a lot of terminal and a multi-port disaster - he read his insurance policy again to see what was covered and found that his business-interuption insurance would not cover any financial loss because of data loss >IF< there were no off-site backups. OTOH another former client called last spring after a disastrous fire. The ONLY data he had was a month old backup of the *n*x system database programs and data that someone had made on a PC. All the filenames were changed to the 8.3 format. For many files that was okay - but there were many processing tables with longer names, which also called other processing tables. The HD's were NOT recoverable I was told - his current HW people had recommended a major company - but everything was pretty well destroyed. I told him that it would take a minium of 100-150 hours of my time to look at the tables, determine the original names, and rebuild it all back to it was the day of the backup. Add that to the HW costs, and he decided it was not worth it and called it a total loss. If the people had made the backup via a proper transfer to MS machine and built an ISO image he would have been ok - but that data loss was made non-recoverable by people not understanding how to make backups that might need to be restored. Sorry you went through this - but at least now you know how to make sure it never happens again. Bill -- Bill Vermillion - bv @ wjv . com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031027150906.GA36540>