A couple of weeks ago I decided to add the
Accurate = yes
flag to my backup jobs. I thought it shouldn't do any harm and
might make restores more precise.
This worked fine until yesterday. Yesterday, all of a sudden,
my incremental backups decided to backup ALL EXISTING FILES
(and not only the changed ones)! At least they tried to - they
ran out of storage, as this was not planned. Luckily, so I
noticed the crap.
I did check the usual possibilities and didn't find a problem -
the timestamps of my files hadn't been tampered with, the fileset
description hadn't been modified, and there was no failed full backup
in the database which could have triggered a new full backup.
Also, the joblog entry looked okay so far:
Backup Level: Incremental, since=2012-01-16 09:12:26
FileSet: "SysBack" 2008-02-10 06:46:30
Scheduled time: 17-Jan-2012 09:12:00
I am doing daily Incrementals and this here correctly shows the time
from Monday morning to Tuesday morning.
I restarted client and server and retried, but still it insisted in
saving EVERY file.
Then I removed the Accurate flag, and instantly the backup worked
as it should!
Then I figured - I had run OffSite backups during the night from
Monday to Tuesday!
My backup scheme is as follows: daily Incremental, monthly Full.
And occasionally I run additional Full backups onto tape, to be
stored in a remote location.
These OffSite backups are using the same Client and Fileset, but
different Job.
And obviousely they do not write Catalog (fileinfo), because these
tapes aren't intended for single-file-restore.
Obviousely these full backups, which have no catalog info, are
used as the information-source for the Accurate flag! And with
no Catalog Info, it looked like there were no files at all contained
in the previous backup, and therefore EVERY file would be saved in
the Incremental, disregarding timestamps.
Understood so far, the solution was simple: I added another
Client-stanza with a different name for each machine, and let the OffSite
Backups run with that different Client name. I modified the old OffSite
jobs in the database to that new Client-id, and now everything seems
to behave fine again.
Then I checked the manual. The manual says:
> In accurate mode, the File daemon knowns exactly which files were
> present after the last backup.
But it does not say how we define "the last backup".
Whereas the "Incremental" Feature clearly defines what is the last
backup:
> all files specified in the FileSet that have changed since the
> last successful backup of the the same Job using the same FileSet
> and Client, will be backed up
So, obviousely the Accurate Flag uses a different information-source
(disregarding the Job name) than the Incremental backup itself.
Operating Version here is
Client: "Disp" 5.0.3 (04Aug10) i386-portbld-freebsd7.4,freebsd,7.4-STABLE
Maybe thats already fixed in newer versions?
But at least with this version, this means you cannot rely on the
Accurate flag when running different Jobs on the same Client and
Fileset; it might loose data.
PMc
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
