Hi,
On Thu, 03 Sep 2009, Kern Sibbald wrote:
> I suspect that all that is already possible with Bacula but may require a bit
> of scripting. In short, you need support from a Bacula specialist, and we
> don't do that on this list (bacula-devel).
Fair enough. I asked for suggested approaches on -users a few weeks ago
but didn't get much back. Perhaps we need to put our hands in our pockets
:-)
> What you are asking for is a bit specialized, so I doubt that it is something
> that would be directly implemented in Bacula, unless we saw that it was
> something a lot of users want, which means it would need to be a very clearly
> defined Feature Request, voted on, then someone would need to volunteer to
> write it.
I hadn't really imagined it to be specialized (long term snapshots without
storing large numbers of full backups with lots of redundant files), but I
guess it must be as there don't seem to be many people popping up who want
it. I did get one positive response on the -users list and I know a lot of
people use the rsync + hard links approach (one drawback of which you
mention below). This proposal is the simplest way I can think of (so far)
to get the same kind of storage efficiency with Bacula's volume storage.
We mostly use disk storage rather than tapes just now, so perhaps it
doesn't make sense for tapes.
I can write up a draft feature request (perhaps trying to state it more
clearly) if that helps. If you guys really don't like the idea you can
always shoot it down anyway, there's no real need for a vote if it's really
not good. Should I use the descriptions in projects.gz as a template?
An alternative description which sets out the potential space savings is
outlined at the end of this email. Apologies to those for whom this is
obvious.
> As I say, the other solution is to ask on the bacula-users list or ask for
> professional help.
>
> Thanks for using Bacula.
Many more thanks for creating it, we're very appreciative :-)
> PS: Be careful with programs like BackupPC that create a lot of hard links.
> If you create enough of them, you will not be able to boot your system
> because fsck must keep track of all the hard linked files in memory, so if
> you have too many hard links and not enough memory, you may one day be stuck.
> The same problem exists with restoring hard links with Bacula. On a normal
> system that has a few hundred or even a hundred thousand, no problem, but if
> you start getting millions of them you may be in trouble.
That's good to be aware of, many thanks. I know that attempting a "du" on
that tree of the filesystem is something that takes an unreasonably long
time right now, which may be an indicator that I need to look at this.
Gavin
If you suppose for the sake of argument that x Bytes of new data get
permanently added to the data set each month, that they don't get removed
(I'd guess this is pretty common on email servers) and that you keep
indefinite monthly snapshots (again, lots of people like long memories on
email servers), the total data consumed by the backups increases as
follows:
total_data(month1) = x
total_data(month2) = 2x + x
total_data(month3) = 3x + 2x + x
total_data(month4) = 4x + 3x + 2x + x
Using the system I've outlined, I think the required storage scales
linearly. Using monthly full backups each time, you get an arithmetic
progression which gets progressively worse. After 12 months, the
arithmetic progression is at 78x, where the linear is at 12x.
Obviously that's a very simplified picture, but I think it reasonably
represents our situation.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
