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
