Am 19.01.2012 00:12, schrieb Peter:
>
> 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
Hi,
I had a similar problem a while back. The thing with accurate backups
is, that only the client name and the fileset are used to identify
previous jobs. Here's the thread:
http://sourceforge.net/mailarchive/forum.php?thread_name=4DD38789.2010007%40informatik.uni-bremen.de&forum_name=bacula-users
Regards,
Christian Manal
------------------------------------------------------------------------------
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
|
