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@xxxxxxxxxx
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@xxxxxxxxxx
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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
