Il 09/08/2016 19:15, Valeri Galtsev ha scritto: > > On Tue, August 9, 2016 11:51 am, Gordon Messmer wrote: >> On 08/08/2016 11:11 PM, Alessandro Baggi wrote: >>> | 78 | backup-fd | 2016-08-08 09:52:57 | B | F | 191,024 | >>> 7,978,295,072 | T | >>> >>> | 79 | backup-fd | 2016-08-08 12:10:31 | B | F | 0 | >>> 0 | A | >>> >>> | 80 | backup-fd | 2016-08-09 03:05:03 | B | I | 191,024 | >>> 7,978,337,100 | T >>> >>> >>> Job with id 79 was aborted due to disk failure. >>> >>> Why, if I have a job full performed on sunday, on monday I got an incr >>> job with the same size? >> >> >> As far as I know, incremental backups include all changes since the last >> full backup. You do have a full backup on 8/8 at 9:52, but that isn't >> the *last* full backup. The last full is 8/8 at 12:10, and it doesn't >> include anything, so all files are changes since the last full backup. > > Well, actually incremental is only the difference between current state > and last backup (whichever it was: incremental, differential, or full). > > In other words, to restore the whole thing to today's date you do: > > 1. restore everything from latest full backup > > 2. restore everything from latest differential backup, which is difference > between latest full backup state and machine state on the day of that > differential backup was performed (if you have more than one diff backup > since full, you choose latest) > > 3. restore everything from all incremental backups performed after last > differential in chronological order > > > Of course, these are the definitions of full, differential, and > incremental that bacula (or bareos) uses. When you are restoring some file > or directory on particular day/time bacula (or bareos) does all necessary > lookups in database to track > full-->differential-->incremental-->...-->incremental history for > particular object (file, symlink, directory,...) and only restores > relevant copy, the one after which object didn't change till requested > day/time. > > I know the terminology they use is a bit confusing, but I hope the scheme > above helps un-confuse it. > > Valeri > >> >> Naturally, I could be wrong, but that's what it looks like from here. >> >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos >> > > > ++++++++++++++++++++++++++++++++++++++++ > Valeri Galtsev > Sr System Administrator > Department of Astronomy and Astrophysics > Kavli Institute for Cosmological Physics > University of Chicago > Phone: 773-702-4247 > ++++++++++++++++++++++++++++++++++++++++ > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos > Hi all, thanks for tips. Reading from bacula.org: "Before doing an Incremental or a Differential backup, Bacula checks to see if there was a prior Full backup of the same Job that terminated successfully. If so, it uses the date that full backup started as the time for comparing if files have changed. If Bacula does not find a successful full backup, it proceeds to do one. Perhaps you canceled the full backup, or it terminated in error. In such cases, the full backup will not be successful. You can check by entering list jobs and look to see if there is a prior Job with the same Name that has Level F and JobStatus T (normal termination). " Now in my env, I've defined a backup jobs and 3 pools (Incr, FULL and Update). In the last case, I've performed a full backup for the job on a different pool (Update pool). This job was canceled by me due to disk failure and at 03:00 incr was perfomed (resulting in a full backup). Now, from bacula.org, if a full backup was stopped/cancelled/geterror (also if the job was runned on another pool), at the next incremental backup (I suppose also differential) a full backup will be performed. It is right? Now if it is right, I will create another job for update backup to remove this issue. Thanks in advance.