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