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]"
Re: Can I bakup like this...??
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 ___ [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...??
Keith Spencer <[EMAIL PROTECTED]> writes: > I need a quick n safe backup strategy. > One that I can get the machine backup super quick if > have to. Okay, that's your main design goal in your backup strategy; fast recovery in case of main disk failure. You're not worrying about fire, etc. > What say you about this...(and "how do I" tips please) > 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. > Then if the original drive hassles me I dump back to > the partition or if the original drive dies, make the > backup drive the active one! Yep. > HELP > How do I do this. Pretty simple; duplicate the first disk on the second in some periodic cron job. Not too often, because if failure occurs during the copy, you'll be toast. > (Disregarding the disaster recovery for the momnet if > necessary) DON'T disregard the disaster recovery procedure. If you have't tested the recovery procedure, then you don't have a working backup system. Other things to note are the fact that if the whole system fails, is stolen, hit by lightning, burned, or so on, your system has no provisions for recovery. Make sure you have another (albeit slower) recovery procedure as well, preferably with off-site backups. ___ [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...??
Freebies - In case this helps: On Wed, 19 Nov 2003, Keith Spencer wrote: > I need a quick n safe backup strategy. > One that I can get the machine backup super quick if > have to. > What say you about this...(and "how do I" tips please) > a) Throw another drive in the box If you can mount a shared drive in another machine, that's even better. > b) Createthe same or at least minimum size partitions > as the active drive You don't need as much space if you compress the record. > c) Cron job to "dump" or tar or ??? the partitions 'man cron' is doubtless your friend here. Write a script that runs your script and invoke it in the daily 'cron' run. Here's the script to cull a number of large but uninteresting directories out of my $HOME and create a compressed backup file. A separate script would "roll" two successive copies of the compressed 'cpio' archive in the backup storage space. I copied the archive out to a Windows 'share' in my employer's backup path the first time I did this. At home, I just manually copy it to a CD. * #!/bin/sh echo "CPIO backup of /home to /tmp/myhomebackup.bz2" echo "List contents with: bunzip2 -kc /tmp/myhomebackup.bz2 | cpio --list" echo "Restore with: cd / ; bunzip2 -kc /tmp/myhomebackup.bz2 | cpio -i -d [-v]" if [ -f /tmp/backuplist ] then rm /tmp/backuplist fi find /home ! -type d -print | grep \/temp\/ -v | grep \/image\/ -v | grep \/incoming\/ -v | grep \/cache\/ -v > /tmp/backuplist cpio -o -H crc < /tmp/backuplist | bzip2 -c - > /tmp/myhomebackup.bz2 echo "Backup created" * The key is making the file '/tmp/backuplist' with the right fully qualified paths to those _files_ (not just the directories) you want to backup. This approach can traverse partitions as needed (depending on where you start your 'find'). 'cpio' also preserves file dates and permissions a bit more gently than 'tar' (or so I understand). If you need "really quick" recovery, you may consider using one of those "hot-swap" IDE disk-drive mounts and have a spare of your _primary_ disk ready to use (and boot, etc.). That saves you the time and trouble of rebuilding the partitions on a new disk, and you only need to backup (and to recover), those directories that are volatile. Now you only need a secondary disk large enough to take the compressed contents of your "live" backup fileset, it need not be bootable, and you save time making and recovering the archive. If you can dump the archive to something like a CD-R/RW, so much the better HTH. - John Mills [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Can I bakup like this...??
Hi all (thanks to Daniela for digging me out of a fsck hole), I need a quick n safe backup strategy. One that I can get the machine backup super quick if have to. What say you about this...(and "how do I" tips please) 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 Then if the original drive hassles me I dump back to the partition or if the original drive dies, make the backup drive the active one! HELP How do I do this. (Disregarding the disaster recovery for the momnet if necessary) Thanks Keith 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]"
