On Thu, 2013-08-08 at 11:08 +0100, Martin Simmons wrote:
> >>>>> On Wed, 07 Aug 2013 19:11:33 -0600, Greg Woods said:
> > | 13 | anathem | 2013-08-02 20:37:18 | B | F | 800,022
> > | 137,247,853,895 | T |
> > | 43 | anathem | 2013-08-07 14:32:19 | B | I | 27,916
> > | 2,345,766,355 | T |
> > | 44 | anathem | 2013-08-07 14:41:45 | B | I | 773,678
> > | 136,134,397,714 | T |
> >
> > I was under the impression that an incremental would only back up files
> > modified since the last backup of any kind, so what made the second
> > incremental act like a full?
>
> Look strange to me too -- it would be interesting to see the logs of these
> backups.
Thanks for taking an interest. This has now become a more-or-less fatal
problem for me as all my Incrementals are getting translated into Full.
At least one of my servers has 735GB of stuff (music, videos, photos,
RPM repositories) that takes over 21 hours to do a full backup on, so
it's important to get Incrementals working the way they should (most of
that stuff never changes, so once backed up once, I shouldn't have to
write it again until the next Full).
I have a feeling that this is related to my attempts to modularize the
director configuration, which I have just done in the past couple of
days. I think the time of that change corresponds with when the problem
started, to it's likely related somehow.
That is, I have a /etc/bacula/clients subdirectory in which I have a
file for each client that defines the File Set and Schedule for each
client (which do vary from client to client of course), and a template
file for the parts of the configuration that are the same for every
client except for the client name. The actual configuration gets put
together with shell scripts run out of bacula-dir.conf, so it looks like
this:
@|"sh -c 'for client in `ls /etc/bacula/clients` ; do sed -e
s/CLIENT-NAME/${client}/ /etc/bacula/bacula-client.conf;
cat /etc/bacula/clients/${client} ; done'"
Here's what's in bacula-client.conf:
Job {
Name = "CLIENT-NAME"
JobDefs = "DefaultJob"
Type = Backup
Schedule = CLIENT-NAME
Client = CLIENT-NAME
File Set = CLIENT-NAME
}
Job {
Name = "CLIENT-NAME-Restore"
Type = Restore
Client=CLIENT-NAME
FileSet="CLIENT-NAME"
Storage = BKUP
Pool = File
Messages = Standard
Where = /tmp/bacula-restores
}
Client {
Name = "CLIENT-NAME"
Address = CLIENT-NAME.gregandeva.net
Catalog = "GregAndEva"
Password = "bkup$ucks"
File Retention = 200
Job Retention = 200
}
For completeness, the DefaultJob is defined as:
JobDefs {
Name = "DefaultJob"
Type = Backup
Level = Incremental
FileSet = "Full Set"
Storage = BKUP
Messages = Standard
Pool = File
Priority = 10
Accurate = yes
Write Bootstrap = "/var/spool/bacula/%c.bsr"
}
And a sample client file:
FileSet {
Name = "anathem"
Include {
Options {
signature = MD5
}
File = /
File = /xp
File = /local
File = /games
File = /home
}
#
# If you backup the root directory, the following two excluded
# files can be useful
#
Exclude {
File = /var/spool/bacula
File = /tmp
File = /proc
File = /tmp
File = /.journal
File = /.fsck
}
}
Schedule {
Name = anathem
}
Maybe another pair of eyes can spot where I messed this up. (If I run
"bacula-dir -t -c /etc/bacula/bacula-dir.conf", it completes
successfully. I can't seem to find any way to have it run the
"preprocessor" and show me what the actual generated bacula-dir.conf
file would look like, although I have manually run the shell command and
the output looks good).
Thanks,
--Greg
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
