Date: Sat, 27 Mar 1999 07:30:05 +1000 From: Greg Black <gjb@comkey.com.au> To: Evgeny Roubinchtein <eroubinc@u.washington.edu> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: "dump" of a "live" file system? Message-ID: <19990326213006.6310.qmail@alpha.comkey.com.au> In-Reply-To: <Pine.A41.4.10.9903252056090.24046-100000@dante30.u.washington.edu> of Thu, 25 Mar 1999 21:10:42 PST References: <Pine.A41.4.10.9903252056090.24046-100000@dante30.u.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
I know this has been answered quite well, but I think there's room for further thoughts on the topic. > Is it possible to "dump" a "live" file system? (i.e. dump a file system > when the machine is in multi-user mode, with the filesystem that is being > dumped mounted read-write). Is it safe/recommended? Strictly speaking, it's not recommended -- but it is done on millions of systems every day, with very few problems. I've been doing it ever since I got my first system that had dump and I've yet to experience a problem. I do follow certain rules to make it safer -- see below. > It seems like this wouldn't be a great idea, since on a "live" file system > mounted read-write there may be pending writes, and it isn't clear how > dump would cope with that. Is it better/ok/safe to first remount the > filesystem read-only? No, this is not going to be a smart move. There are too many things that can break if you try this on a running system. If you want to be certain, then you have to shutdown and run the dump in single user mode -- this can be automated simply enough from cron and using rc scripts to handle things. However, most systems have so little need for their backups that the potential inconvenience of such a shutdown is not worth it. As a rule of thumb, this is what I do. * Create level 0 dumps of the entire system when it's installed and put those tapes aside. * Run all backups as incrementals at various levels after that (meaning that they are completed in a few minutes on most machines). * Schedule the backups at the quietest time of day (which varies from system to system, but is often between 0200 and 0400). * Never schedule the backups (or anything else run by cron) during the window for daylight time changes in those primitive places that use daylight time. * Ensure that no other cron jobs run at the same time as the backups. * Where feasible, disallow logins during the backups; have /etc/nologin contain a message that a backup is in progress and should be finished at a certain time. If this is not feasible, have a message presented to users logging in that the backup is in progress and that files that are altered during this time may not be backed up correctly. Whether new logins are permitted or not, warn all currently logged-in users that the backup is in progress (as above). * When the next OS release arrives, avoid the upgrade option, since nobody has ever got these right; go single user and do new level 0 dumps of all the user and config stuff (which is kept on different partitions from the OS stuff); install the new OS; restore the dumps; repeat step 1. There are parts of this that will strike some people as quite unsuitable to their situation and it's certainly not a complete recipe for success in all cases. However, it should give you something to think about and to work from. It's served me well for many years on a diverse set of systems. -- Greg Black <gjb@acm.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990326213006.6310.qmail>