C7 Backup Problem

Home » CentOS » C7 Backup Problem
CentOS 5 Comments

Good morning list, I’ve a question about backup performed with bacula. I manage a DELL server (dedicated on provider) with C7. I use bacula as backup system with volumes on disk. System performs mon-sat incremental backups and Sun full backup at 03.00 AM. I’ve another pool (named update) where I performs backup before each software update. Storage is on and external disk 2.5′ of 1TB.

Yesterday, I’ve applied CentOS update and I’ve performed a full backup before apply updates. Job done.

After several hours, I got my disk unmounted and disconnected due to disk error (seems that this disk is failing) and was unable to remount disk. Rebooting system, the disk was mounted correctly.

This morning I’ve checked if something happened. Backup performed and disk mounted without errors but I’ve noticed a strange behaviour.

My incremental backup is large as last full backup (performed on sunday). This is the last jobs performed.

76 | backup-fd | 2016-08-07 03:04:44 | B | F | 191,040 |
7,975,649,059 | T |
| 77 | backup-fd | 2016-08-08 03:04:57 | B | I | 44 |
44,593,988 | T |

| 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? Seems to be that the last incremental job was performed without considering the last full backup.

I’ve checked log but there aren’t errors.



5 thoughts on - C7 Backup Problem

  • My wild guess would be: if drive fails filesystem might get remounted read-only on the fly, then bacula will discover the difference in permissions (r-x instead of rwx) and will back up the file again, no matter that it already is in full backup. Whichever time it was read only:
    could be full: r-x incremental rwx or other way around.

    Again, this is not a diagnostics, just a wild guess, but you have both backups: find out which file was backed up both times though didn’t change, restore both versions, compare permissions, and compare contents. And hopefully you will know the answer, or at least you will get the hint
    _why_ while you will be doing this.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Valeri Galtsev wrote:

    I’m using bareos to back up a bunch of PC workstations.

    First question: do you have the .conf file set to reuse or not?

    My first guess is, if the d/b was corrupted, or it couldn’t append to the incremental, or full, then it would decide the whole thing was new, and
    “incremental” would be a full b/u.

    mark, who’s just finished working with his manager on a decent nightly
    b/u report for bareos

  • 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.

    Naturally, I could be wrong, but that’s what it looks like from here.

  • 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 Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Il 09/08/2016 19:15, Valeri Galtsev ha scritto:

    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.