Date: Thu, 24 May 2007 12:01:44 -0400 From: Jerry McAllister <jerrymc@msu.edu> To: Jason Lixfeld <jason+lists.freebsd-questions@lixfeld.ca> Cc: freebsd-questions@freebsd.org Subject: Re: Backup advice Message-ID: <20070524160144.GD4322@gizmo.acns.msu.edu> In-Reply-To: <031D3633-5CE3-4962-961A-F879C3CF1949@lixfeld.ca> References: <28E0DBBA-BB24-4D6B-AE65-07EB5254025C@lixfeld.ca> <23E233D0-EBD1-4779-8334-8124031CDD64@lafn.org> <C8C214C7-A11A-489E-83C1-0C81EB3564C8@lixfeld.ca> <BB43EF6A-F00C-40F0-9B8C-E4B6BF0C140D@lafn.org> <031D3633-5CE3-4962-961A-F879C3CF1949@lixfeld.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 24, 2007 at 03:10:43AM -0400, Jason Lixfeld wrote: > > On 24-May-07, at 12:33 AM, Doug Hardie wrote: > > > > >On May 23, 2007, at 19:03, Jason Lixfeld wrote: > > > >> > >>On 23-May-07, at 9:23 PM, Doug Hardie wrote: > >> > >>>The criteria for selecting a backup approach is not the backup > >>>methodology but the restore methodology. > >> > >>Excellent point. > >> > >>Perhaps I'm asking the wrong question, so let me try it this way > >>instead: > >> > >>software goes. > > > >What kind of data are you backing up? If you are backing up the > >system and your data then you have to be very careful about links. > >Some backup solutions will copy the files as separate files. When > >you restore the link is gone. An update to one of the linked files > >will no longer be seen by the other names. The OS uses a lot of > >links. If all you are backing up is data, its probably not an > >issue. Yes, I neglected to mention the issue of veracity of the backups. dump/restore is the only one that completely handles the hard links the way you want. It may also be the only one that handles ACLs properly if you use those. I haven't examined that issue. > > Dump seems to be the best at doing what I'm looking to do. Better > than tar or rsync. I think dd would beat out dump, but dd is far > less of a backup tool than dump is, so I think dump is still the > winner. The caveat of a full dump taking the most time and resources > can be reasonably mitigated by doing a full dump every X intervals > and incremental in between. It seems to be a fair compromise seeing > as how cheap hard drive space is these days. Note that dd is not really a backup utility. It is a data copy utility. If you have a catastrophic failure on a disk and need to replace it, there is every likelihood that the new drive will NOT be exactly like the old one. Doing a disk build with fdisk, bsdlabel and newfs and restoring from dumps would get you exactly what you want. But, using dd would not. You would have an exact copy of the old boot sectors, MBR, partition tables which would not be correct for the new drive (although they might work, sort of). > > 2 x system space would be enough for a full dump plus plenty of > increments, I'd say. No? Is there a rule of thumb? 3x? 4x? Depends a lot on how much your data changes. In your case, that would include log files, since you intend to back up the whole system. Other than log files, the system itself will not change a lot. But, I have no idea of what your data does. I would feel comfortable with 2X for my sort of stuff and be able to do a full, plus maybe half a dozen incrementals or so. But even 4X might not cover it for some volatile systems. > As far as restoring goes, let's assume my machine blew up one full > backup and 15 increments ago and I want to restore the entire system > in it's entirety from my backup. How is that done? Point restore to > the last incremental and it figures it out for itself, or is it a > manual process where I have to figure out what backups consist of the > complete system? No, you first restore the full dump and continue through the incrementals in order of increasing level. If you made more than one incremental at a specific level, then only restore from the last one made. > > >One backup disk is not all that great a safety approach. You will > >never know if that drive has failed till you try and use it. Then > >its too late. Failures do not require that the drive hardware has > >failed. Any interruption in the copy can cause an issue that may > >not be detected during the backup. Sectors generally don't just go > >bad sitting on the shelf, but it does happen. That was a > >significant problem with tapes. Generally 25% of the tapes I used > >to get back from off-site storage after a month were no longer > >readable. > > There has to be some way for the OS to know if a drive is bad, or to > verify the state of the data that was just copied from one location > to another. Is there no method of doing error correction? My laptop > backup programs I've been using for years shows me information at the > end of the run: Files copied, Speed, Time, Errors, etc. The OS does see read/write errors on a disk and reports them. dump will tell you if it thinks there was a media error, but that doesn't tell you much - and probably doesn't really on your laptop. It is probably a false sense of security. There used to be a verify option on dump, or maybe it was in some other proprietary version of UNIX I worked on. But it made dumps take so long that we quickly gave up using it. It required reading back the media and comparing it to the original. Then the verify often failed because a file was changed or deleted between the time it was written and the time it was verified. So, the verify was not useful. > > If a UNIX backup process is as unreliable as you're making it out to > be, then I could buy 10 drives and still potentially have each one > fail and be screwed if I were to need to rely on it at some point. It is actually quite reliable. But, many things can happen. The same disaster that nuked your original disk drive, can also nuke your drive with the backup. Other accidents can happen with the handling of media. Try dropping one of those drives on a hard floor and then reading from it. You might get some stuff off... Thus, you should keep extra backups offsite and possibly use more than one type of media if your data is critical and changes a lot. > > I'd feel more comfortable backing up off a RAID1 to a single backup > drive that provided some sort of error protection/correction/ > notification than backing up off a RAID1 to 100 backup drives that > didn't give me any indication as to the success of the copy. Well, see my paragraph above. ////jerry > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070524160144.GD4322>