Bacula-users

Re: [Bacula-users] Bacula says it is doing incremental backup but does full backup.

2008-07-08 17:27:55
Subject: Re: [Bacula-users] Bacula says it is doing incremental backup but does full backup.
From: Hemant Shah <hjrrs AT yahoo DOT com>
To: baculausers <bacula-users AT lists.sourceforge DOT net>
Date: Tue, 8 Jul 2008 14:27:44 -0700 (PDT)

Hemant Shah
E-mail: hjrrs AT yahoo DOT com


--- On Tue, 7/8/08, Arno Lehmann <al AT its-lehmann DOT de> wrote:

> From: Arno Lehmann <al AT its-lehmann DOT de>
> Subject: Re: [Bacula-users] Bacula says it is doing incremental backup but 
> does full backup.
> To: "baculausers" <bacula-users AT lists.sourceforge DOT net>
> Date: Tuesday, July 8, 2008, 3:58 PM
> Hi,
> 
> 08.07.2008 21:55, Bruno Friedmann wrote:
> > Ahem ... it seems very stupid the question I ask but
> re-reading all the thread someting appear to me.
> > 
> > They are 2 distinct pools ... but they are not specify
> in the schedule.
> > So 1 one full backup for your pool
> > Pool:                  
> "lidp11-FullBackupDiskPool" (From Job FullPool
> override)
> > and 1 full for the pool
> > Pool:                  
> "lidp11-IncrBackupDiskPool" (From Job IncPool
> override)
> > 
> > So there's no bug just a mistake :-)
> > 
> > So your schedule should be
> > Run = Level=Full Pool=lidp11-FullBackupDiskPool 1st
> fri at 21:00
> >  Run = Level=Incremental
> Pool=lidp11-IncrBackupDiskPool sun-thu at 22:00
> > and so on ...
> 
> Erm... no, not necessarily.
> 
> It's perfectly valid to have full, differential and
> incremental jobs 
> going to distinct pools.
> 
> I'd even say this is common practice.
> 
> I'd suggest to find one file that should *not* have
> been backed up in 
> the incremental and stat it.
> 
> Like this:
> 
> [arno@bacula ~]$ stat wget-log
>    File: `wget-log'
>    Size: 2881            Blocks: 8          IO Block: 4096 
>  regular file
> Device: 805h/2053d      Inode: 8323098     Links: 1
> Access: (0664/-rw-rw-r--)  Uid: ( 1001/    arno)   Gid: (
> 1002/    arno)
> Access: 2008-07-02 23:51:26.000000000 +0100
> Modify: 2008-04-19 20:58:01.000000000 +0100
> Change: 2008-04-19 20:58:01.000000000 +0100
> 
> If any of the time stamps are in the future, or are after
> the initial 
> full backup, you'll have t find why that is the case.
> 
> Virus scanners are a common problem here, but - as someone
> pointed out 
> - a file creation time in the future also happens. One good
> reason to 
> implement reliable time sources like ntp.

All but 2 systems are Unix so there are no Virus scanners running. Bacula did 
full backup on 27 clients. The chances of all the files on all 27 clients 
having future timestamp is unlikely. I am also using ntp on all systems.

I ran stat on 4 files that were backed up and their timestamps were not in 
future:


[root@lidp11 ~]# stat /lib64/libSegFault.so /lib64/libplc4.so 
/lib64/libexpat.so.1.5.2 /lib64/libe2p.so.2.3
File: `/lib64/libSegFault.so'
Size: 22152           Blocks: 48         IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 8203        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-07-04 21:56:22.000000000 -0500
Modify: 2008-05-05 07:37:05.000000000 -0500
Change: 2008-06-13 12:39:59.000000000 -0500
File: `/lib64/libplc4.so'
Size: 18672           Blocks: 40         IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 8585        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-07-07 21:57:55.000000000 -0500
Modify: 2008-06-02 06:00:37.000000000 -0500
Change: 2008-06-13 21:10:54.000000000 -0500
File: `/lib64/libexpat.so.1.5.2'
Size: 169880          Blocks: 344        IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 8418        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-07-07 04:31:59.000000000 -0500
Modify: 2008-02-25 05:56:44.000000000 -0600
Change: 2008-06-13 21:09:40.000000000 -0500
File: `/lib64/libe2p.so.2.3'
Size: 26752           Blocks: 56         IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 8388        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-07-04 21:56:22.000000000 -0500
Modify: 2008-05-12 14:03:14.000000000 -0500
Change: 2008-06-13 21:16:15.000000000 -0500

I did not have this problem when I was testing with 2.2.8.

> 
> Arno
> 
> > If I don't make a mistake or a misunderstood, but
> I'm pretty sure to give my brain sufficient time
> > and to some test to have this working like this in my
> installations.
> > 
> > Hope this give you an awnser, and a better backup time
> !
> > 
> > 
> > 
> > 
> > Hemant Shah wrote:
> >> Hemant Shah
> >> E-mail: hjrrs AT yahoo DOT com
> >>
> >>
> >> --- On Tue, 7/8/08, Arno Lehmann
> <al AT its-lehmann DOT de> wrote:
> >>
> >>> From: Arno Lehmann <al AT its-lehmann DOT de>
> >>> Subject: Re: [Bacula-users] Bacula says it is
> doing incremental backup but does full backup.
> >>> To: "baculausers"
> <bacula-users AT lists.sourceforge DOT net>
> >>> Date: Tuesday, July 8, 2008, 2:44 AM
> >>> Hi,
> >>>
> >>> 07.07.2008 19:46, Hemant Shah wrote:
> >>>> Folks,
> >>>>
> >>>>   I ran my first production backup of
> bacula last
> >>> weekend. I did a full backup to tape, then
> full backup to
> >>> disk. Next was incremental backup. Bacula said
> that it was
> >>> doing incremental backup but it actually did a
> full backup.
> >>> I am running bacula 2.4.0. Here are the
> e-mails I received.
> >>>> Fullbackup:
> >>>>
> >>>>   Build OS:              
> x86_64-unknown-linux-gnu
> >>> redhat
> >>>>   JobId:                  39
> >>>>   Job:                   
> >>> lidp11-BackupToDisk.2008-07-04_21.04.42
> >>>>   Backup Level:           Full
> >>>>   Client:                
> "lidp11-fd" 2.4.0
> >>> (04Jun08) x86_64-unknown-linux-gnu,redhat,
> >>>>   FileSet:                "lidp11
> Disk set"
> >>> 2008-07-04 21:04:05
> >>>>   Pool:                  
> >>> "lidp11-FullBackupDiskPool" (From
> Job FullPool
> >>> override)
> >>>>   Storage:               
> "lidp11-File"
> >>> (From Pool resource)
> >>>>   Scheduled time:         04-Jul-2008
> 21:04:01
> >>>>   Start time:             05-Jul-2008
> 18:14:14
> >>>>   End time:               06-Jul-2008
> 05:01:39
> >>>>   Elapsed time:           10 hours 47 mins
> 25 secs
> >>>>   Priority:               10
> >>>>   FD Files Written:       2,417,797
> >>>>   SD Files Written:       2,417,797
> >>>>   FD Bytes Written:       60,253,728,260
> (60.25 GB)
> >>>>   SD Bytes Written:       60,550,530,761
> (60.55 GB)
> >>>>   Rate:                   1551.1 KB/s
> >>>>   Software Compression:   52.7 %
> >>>>   VSS:                    no
> >>>>   Storage Encryption:     no
> >>>>   Volume name(s):        
> >>> Full-lidp11-2008-07-05-18:14:13
> >>>>   Volume Session Id:      39
> >>>>   Volume Session Time:    1215182293
> >>>>   Last Volume Bytes:      60,661,172,712
> (60.66 GB)
> >>>>   Non-fatal FD errors:    0
> >>>>   SD Errors:              0
> >>>>   FD termination status:  OK
> >>>>   SD termination status:  OK
> >>>>   Termination:            Backup OK
> >>>>
> >>>>
> >>>> Incremental Backup:
> >>>>
> >>>>   Build OS:              
> x86_64-unknown-linux-gnu
> >>> redhat
> >>>>   JobId:                  70
> >>>>   Job:                   
> >>> lidp11-BackupToDisk.2008-07-06_22.00.30
> >>>>   Backup Level:           Incremental,
> >>> since=2008-07-05 18:14:14
> >>>>   Client:                
> "lidp11-fd" 2.4.0
> >>> (04Jun08) x86_64-unknown-linux-gnu,redhat,
> >>>>   FileSet:                "lidp11
> Disk set"
> >>> 2008-07-04 21:04:05
> >>>>   Pool:                  
> >>> "lidp11-IncrBackupDiskPool" (From
> Job IncPool
> >>> override)
> >>>>   Storage:               
> "lidp11-File"
> >>> (From Pool resource)
> >>>>   Scheduled time:         06-Jul-2008
> 22:00:00
> >>>>   Start time:             06-Jul-2008
> 22:05:25
> >>>>   End time:               07-Jul-2008
> 06:26:42
> >>>>   Elapsed time:           8 hours 21 mins
> 17 secs
> >>>>   Priority:               10
> >>>>   FD Files Written:       2,096,136
> >>>>   SD Files Written:       2,096,136
> >>>>   FD Bytes Written:       58,910,683,776
> (58.91 GB)
> >>>>   SD Bytes Written:       59,167,747,657
> (59.16 GB)
> >>>>   Rate:                   1958.7 KB/s
> >>>>   Software Compression:   52.4 %
> >>>>   VSS:                    no
> >>>>   Storage Encryption:     no
> >>>>   Volume name(s):        
> >>> Incr-lidp11-2008-07-06-22:05:25
> >>>>   Volume Session Id:      68
> >>>>   Volume Session Time:    1215182293
> >>>>   Last Volume Bytes:      59,271,542,084
> (59.27 GB)
> >>>>   Non-fatal FD errors:    0
> >>>>   SD Errors:              0
> >>>>   FD termination status:  OK
> >>>>   SD termination status:  OK
> >>>>   Termination:            Backup OK
> >>>>
> >>>>
> >>>> As you can see the amount of data backups
> is almost
> >>> the same (60GB).
> >>>> This was done over a long weekend, so very
> few files
> >>> changed on this filesystem. 
> >>>
> >>> As there are some jobs between those two you
> reported I
> >>> suspect there 
> >>> was another attempt to run a full backup which
> was
> >>> cancelled (either 
> >>> manually or automatically) to run a backup
> while the first
> >>> full was 
> >>> still active.
> >>>
> >>> This would have left an aborted or canceled
> full job in the
> >>> catalog, 
> >>> forcing the incremental to get upgraded. Is
> that possible?
> >>  No, there were no aborted of canceled jobs, I
> have scheduled them with different priorities so that they
> do not interfere with each other. If the backup was
> upgraded to Full then there would have been a warning
> message in the e-mail, I have seen that happen during my
> testing.
> >>
> >> Here is my schedule, the tape backups run at
> priority 5 and disk backups run at priority 10.
> >>
> >> Schedule
> >> {
> >>   Name = FullBackupToTape
> >>   Run = Level=Full Storage=DLT_Drive SpoolData=yes
> 1st fri at 20:00
> >> }
> >>
> >> Schedule
> >> {
> >>  Name = BackupToDisk
> >>  Run = Level=Full 1st fri at 21:00
> >>  Run = Level=Incremental sun-thu at 22:00
> >>  Run = Level=Incremental 2nd fri at 22:00
> >>  Run = Level=Incremental 3rd fri at 22:00
> >>  Run = Level=Incremental 4th fri at 22:00
> >>  Run = Level=Incremental 5th fri at 22:00
> >>  Run = Level=Incremental 2nd sat at 22:00
> >>  Run = Level=Incremental 3rd sat at 22:00
> >>  Run = Level=Incremental 4th sat at 22:00
> >>  Run = Level=Incremental 5th sat at 22:00
> >> }
> >>
> >> Schedule
> >> {
> >>  Name = VmwareToTape
> >>  Run = Level=Full Storage=DLT_Drive SpoolData=yes
> 1st fri at 21:00
> >> }
> >>
> >> Schedule
> >> {
> >>  Name = VmwareToDisk
> >>  Run = Level=Full Fri at 23:00
> >> }
> >>
> >>
> >>
> > 
> > 
> > 
> 
> -- 
> Arno Lehmann
> IT-Service Lehmann
> www.its-lehmann.de
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE
> NOW!
> Studies have shown that voting for your favorite open
> source project,
> along with a healthy diet, reduces your potential for
> chronic lameness
> and boredom. Vote Now at
> http://www.sourceforge.net/community/cca08
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users


      

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

<Prev in Thread] Current Thread [Next in Thread>