On Tuesday 02 January 2007 14:30, James Harper wrote: > > 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.
No not quite. That is a bit too complicate. I am talking about a small extension to what distros already supply. Basically all we need to do is exactly what I said above, and what I have requested is totally generic in that it has nothing to do with Bacula. The distro supplier doesn't have to know anything about Bacula. The installer stuff I mentioned would just be some extra icing on the cake that would facilitate the recovery for less command line oriented people. > > 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". You would have to burn at least one CD that was Bacula aware. If the distro provider supplies a rescue disk as I noted in my previous email, we would then just hook in some scripts that would automate getting to the data that you have backed up (as you describe above). > > 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. In the mode you suggest above, you would probably be better using tar. If you are not taking a tape off-site every night, there is no need to remove it. Bacula can very easily handle the different backup levels. Multiple levels and multiple tapes is no more complicated than one. That's what a good computer program will do for you ... :-) ------------------------------------------------------------------------- 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
