Re: Can I bakup like this...?? <--user mode Reuben?
Keith Spencer <[EMAIL PROTECTED]> writes: > I just spent many hours finding out my bakup strategy > was useless (didn't know what I was doing I guess) You don't really have a backup strategy unless you have tested it. I just finished building myself a new backup system, and I had to run it through a few iterations before I was happy with everything it did (including testing boundary cases like running out of space and so on). > Now I need to do it properly. Sure, but first you need to understand (at least loosely) what your idea of "properly" is for this particular machine. This is something that you need to determine before you start working out the technical approach. You implied in an earlier message that your main priority is minimum downtime. If so, you were probably on the right track with your strategy of a second disk in the box, kept reasonably up-to-date automatically, and ready to be swapped in as the primary disk. If this disk is a server, with a lot of user data, then that probably isn't enough, and you need periodic backups that don't get overwritten. If you really need minimum downtime, then dropping to single-user mode for backups won't be practical. You'll need to keep the second disk synched with the first by some method that will work fairly dependably in multi-user mode. Either dump/restore or tar will do fairly well; there will be some race conditions where some files could end up improperly synched, but those conditions are unlikely and easy to recover from (if you have another, user-data focused, backup strategy as well). Good luck. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can I bakup like this...?? <--user mode Reuben?
On Thu, Nov 20, 2003 at 01:28:35PM +1100, Keith Spencer wrote: > Hi all, thanks to all replying. > I just spent many hours finding out my bakup strategy > was useless (didn't know what I was doing I guess) > Now I need to do it properly. > Ruben (and others) > Can I do the tarring of filesystems in a cron job > without being in single user mode? > I just followed a mostgraveconcern tute to move to a > larger drive and it worked well. > Lots of tarring etc BUT...all done in single user > mode. I imagine I cant do THAT and reboot etc etc in a > cron job. > I am going to try Ruben's idea and allay concerns by > having a removable 2nd harddrive so I can do this > > once to take a drive off site > So comments? > Is dump easier (for a dill like me) to use or > whatever? The point of dropping to single user mode when doing disk copies is primarily to make sure that nothing is going to be writing to the disks during the copying process. (There's a subsidiary consideration when copying some files owned by eg. databases, where the on-disk state of the file does not correspond with the actual state of the data, and you need to do a clean shutdown to get everything synchronised, so that the database can start up again cleanly.) If you can achieve the same effect by other means then that's just as good. However, on the whole, dropping to single user is going to be the easiest and quickest way of doing this sort of thing. The same considerations apply to doing backups, but usually dropping to single user is not going to be feasible in that case. The strategy in this case is simply to do the best that you can to avoid problems: backups should be run while the system is quiet, which usually equates to the small hours of the morning. In 5.x there's a new facility to "snapshot" a filesystem, which essentially holds off all pending disk writes in order to let a backup process complete. Now, you can't absolutely guarrantee that your backup will contain a completely consistent view of a file system (generally because you cannot run the backup instantaneously). However, most of the time an only-slightly inconsistent view is good enough. For this reason, and to insure yourself against failure of your backup media you should always aim to have multiple copies of your backups available. Now, you could just run two backups every night onto separate sets of media, but that's really far too expensive, so generally people will opt for having several sets of backup media and cycling through them. Maybe the tape drive shredded your backup tape from last night, but you'll still have the tape from the night before. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: Can I bakup like this...?? <--user mode Reuben?
Hi all, thanks to all replying. I just spent many hours finding out my bakup strategy was useless (didn't know what I was doing I guess) Now I need to do it properly. Ruben (and others) Can I do the tarring of filesystems in a cron job without being in single user mode? I just followed a mostgraveconcern tute to move to a larger drive and it worked well. Lots of tarring etc BUT...all done in single user mode. I imagine I cant do THAT and reboot etc etc in a cron job. I am going to try Ruben's idea and allay concerns by having a removable 2nd harddrive so I can do this > once to take a drive off site So comments? Is dump easier (for a dill like me) to use or whatever? What say you Thanks Keith --- Ruben de Groot <[EMAIL PROTECTED]> wrote: > On Wed, Nov 19, 2003 at 09:43:30AM -0500, Lowell > Gilbert typed: > > Keith Spencer <[EMAIL PROTECTED]> writes: > > [...] > > > > a) Throw another drive in the box > > > b) Createthe same or at least minimum size > partitions > > > as the active drive > > > c) Cron job to "dump" or tar or ??? the > partitions > > > > dd(1) is the easiest way to make sure that the > disk will work just > > like the other one. It requires a > same-size-or-larger second disk. > > I consider dd a very lousy backup method. Any writes > to the first disk > while dd is running will likely result in corrupted > filesystems on the > second disk. Performance is bad as well, since dd > will copy every single > bit, not just actual data. > > A better approach would be to follow a) and b) > above, newfs(8) the > partitions, make the second drive bootable using > boot0cfg(8) and then > periodically use dump/restore, tar, pax, cpio or > even rsync to backup > your first to second disk (I've used them all and > can't really > recommend one over the other so suit yourself). > > Ruben > http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
