> What I would like to see, and where I would be happy to participate, is to > convince the OS vendors (i.e. RedHat/Fedora, SuSE, Debian, Ubantu, > FreeBSD, > Solaris, HP, ...) that they should have an easy way for the user to make a > rescue disk that captures the state of the current harddisk(s) and > provides > easy scripts, or better yet a GUI, for repartitioning those disks much > like > they do in the installation. This rescue disk should not be a bare bones > rescue with few binaries as is currently the case, but something that > includes every conceivable command line program one would want in > analysing > and fixing a problem. > > Furthermore, the user should be able to include a large number of machine > configurations on a single rescue CD as well as to be able to add one > directory to be loaded in memory at boot time and one directory to be > saved > on the CD. With that, everyone should be happy. > > The above should be a *standard* part of the OS release. >
Wouldn't that be great! I was looking very briefly at doing this under Debian, I guess the idea would be that you take the installer and add some more stuff to it (bacula-fd, -sd, and -dir), and then remove most of the stuff that does the actual installation. As I mentioned in another email, the Backup Exec IDR does almost exactly that - it creates a CD derived from your installation media but with some hooks in place to call the installer after the base operating system is installed, which has the advantage that the base operating system is configured for the current hardware and not the hardware of the system that was originally backed up, which may be different. My ultimate wish is that you wouldn't have to do any real preparation (burning CD's etc) for a disaster other than taking your tapes off site nightly and making sure that your system state info is on that tape. The recovery procedure would first extract the system state from the tape, apply it, then restore everything. There would be a few levels of automation ranging from "everything is on this single tape, the client name is xxx, restore it", to "I want to set up my partitions a little differently this time, and I want to restore the last full backup which was two weeks ago and then all the differentials since then except for last night when the rootkit was installed". The restoring system state from tape idea should be pretty simple if your director, catalogs, and sd are still running as you could identify it and restore it pretty simply. In fact, if you defined a job that restores the state and then runs the apply script as a 'run after job', you could drive it all from the director as long as nothing went wrong. (or do the scripts not work on a restore?) Restoring the system state from tape when your entire network is in pieces is obviously a bit harder, especially if you aren't doing a simple one tape = one nights backup model. Our client base is mostly small businesses with <100 employees who use Symantec Backup Exec or NTbackup. Most of the time the backup tape is changed blindly each morning. My philosophy for such businesses is that if everything can't fit on a single tape, you need a bigger storage solution. Two tapes or differentials get too complicated, and when things get complicated they get done badly. Obviously everything changes for larger organisations or organisations that just have more data than can be physically spooled to tape in a single night. James ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
