On 08/26/10 05:04, m...@free-minds.net wrote: > Hello, > I think this is a common question but i didnt found a proper answear in > the documentenation, if there is already one please let me know :) > > So we have now successfully set up our Bacula Servers and everything is > now running more or less... > But we have some questions: > 1) do we really need to spool? We are not writing to real tapes, we have a > filesystem as backend (ext3 over glusterfs).
If you're using a disk backend, honestly, there is really no reason whatsoever to use spooling. Spooling is designed pretty much for one situation, the case in which you have slow clients and a fast tape drive, the clients cannot supply the tape drive with data fast enough to keep it streaming, and you don't mind the backup taking longer overall (because the same spool buffer cannot spool and despool simultaneously, so they have to take turns) in order to avoid shoeshining the tape. The other situation in which spooling might be useful is when you're backing up to remote storage over a slow connection, but want the backup to complete (at your end) quickly and have sufficient local disk to spool the entire backup before it gets written out to long-term storage over your outgoing connection. By the sound of it, neither of these is applicable to you. > 2) should we backup our whole system or just our data? I heard several > concepts what we really should backup... Because if we have lost our server > and the database isnt restorable, we cant restore the whole system, because > file attrs are lost and every file will get 664 or something like that... If some of your data needs to be in place before other parts can be correctly restored, that can usually be handled by properly designing your backup filesets. As a general rule, you should not back up the contents of dynamic filesystems like /sys and /proc (on Linux) or /devices (on Solaris), and there is little point in backing up data that you don't really care about (like browser caches and contents of /tmp) or OS elements that have to be reinstalled by other means before you can restore your backup set in the first place (assuming you don't have a tested and verified bare-metal restore solution in place). > Also I heard that a restore of the whole system is very slow, we should > install a fresh debian, install our packages and restore our data. > actually we have arround 80GB of Full backup (takes arround 17h) and 10GB > incremental (takes arround 2-3h). If we only backup the real data it would > be much lesser... 17 hours to back up 80GB to disk? Good grief! You have a SERIOUS bottleneck somewhere in your system. I use an LTO-2 drive for full backups, which is slower than almost any decent disk system should be, and my system backs up half a terabyte in five to six hours. 10GB should take only minutes. The incremental backup last night of my main server, which backed up 98GB of data out of roughly 1.5TB, took only about an hour, most of which was spent scanning the disk farm for changes. If your backup medium is THAT slow, it might actually be quicker to reinstall the base OS. But remember that all your settings, patches, customizations, OS metadata will be lost that way too. At the very least, you need to back up all your system settings under /etc. The question is not just "Does a restore take longer than reinstalling?", it's "Does a restore take longer than reinstalling and then recreating all of the metadata, configuration settings and customizations by hand?" -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users