[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Trying out the VirtualFull feature.


Hello,

On Thursday 14 August 2008 16:00:44 Graham Keeling wrote:
> On Wed, Aug 13, 2008 at 06:34:59PM +0200, Kern Sibbald wrote:
> > Start with something far simpler.  It looks like you are writing to
> > multiple pools, and maybe that is creating problems.
>
> OK, I've made my configuration simpler. It is now as follows, but I'm still
> getting the same problem with the vbackup not including the incremental.
>
> Storage {
>   Name = "C"		# 'C' for Consolid pool
>   Address = "192.168.100.121"
>   SDPort = 9103
>   Password = "password"
>   Device = 0.1
>   Media Type = File
> }
>
> Storage {
>   Name = "N"		# 'N' for Normal pool
>   Address = "192.168.100.121"
>   SDPort = 9103
>   Password = "password"
>   Device = 0.0
>   Media Type = File
> }
>
> Pool {
>   Name = "Consolid"
>   Pool Type = Backup
>   Recycle = yes           # automatically recycle Volumes
>   AutoPrune = yes         # Prune expired volumes
>   Volume Retention = 1 week
>   Maximum Volume Jobs = 1
>   Label Format = backup-
>   Maximum Volumes = 0     # unlimited
>   RecyclePool = Scratch
>   Storage = "C"
> }
>
> Pool {
>   Name = "Normal"
>   Pool Type = Backup
>   Recycle = yes           # automatically recycle Volumes
>   AutoPrune = yes         # Prune expired volumes
>   Volume Retention = 1 week
>   Maximum Volume Jobs = 1
>   Label Format = backup-
>   Maximum Volumes = 0     # unlimited
>   RecyclePool = Scratch
>   Next Pool = "Consolid"
>   Storage = "N"
> }
>
> Job {
>   Name = "ABC"
>   Type = Backup
>   Schedule = "ABC"
>   Messages = Standard
>   Pool = "Normal"
>   Client = "ABC-fd"
>   FileSet = "ABC"
>   Storage = "N"
>   Accurate = yes
> }

Yes, thanks for simplifying it.  Right off, I can say that I don't think the 
above will work because you are dealing with two "different" storage daemons, 
and Bacula doesn't know how to deal with that situation.  It cannot read from 
one and write to another one.  They must be the same storage daemon, which 
means they both must be defined in the same Storage resource.

Try working your example down to a single Storage resource.

>
> > Turn on debug mode -d150 in the director that may give you a better idea
> > of what is going on -- e.g. it will probably print the .bsr file.
> >
> > Take a look at the bsr file it has produced.  If it doesn't have the
> > incremental then something is wrong.
> >
> > You might try creating a bsr file with the "restore" command before you
> > do the Vbackup, and compare it to the one generated by the Vbackup.  They
> > should be identical.  If not, it will probably give us some idea what is
> > going wrong.
> >
> > Also when running the vbackup, if you set debug level to at least 100 it
> > will tell you what jobids it is going to combine.
> >
> > Uncomment a few lines in src/dird/vbackup.c at lines 495 and 496 to see
> > what the bsr file looks like.
>
> OK, I've now got a restore bsr file, and then got the output of print_bsr()
> from uncommenting those lines when running the vbackup afterwards.
> The restore one has both volumes listed, and the vbackup one only has
> onelisted. This time, the Full is in backup-0001 and the Incremental is in
> backup-0002. Here is what is in the restore bsr file, which looks correct
> to me:
>
> Volume="backup-0001"
> MediaType="File"
> VolSessionId=1
> VolSessionTime=1218720413
> VolFile=0
> VolBlock=217-431832
> FileIndex=1-513
> FileIndex=515-524
> Count=523
> Volume="backup-0002"
> MediaType="File"
> VolSessionId=2
> VolSessionTime=1218720413
> VolFile=0
> VolBlock=217-2304
> FileIndex=1
> Count=1

Yes, this looks pretty reasonable.

>
> Here is print_bsr() from running a vbackup (tidied up to remove syslog
> cruft). This misses out 'backup-0002'.
>
> Volume="backup-0001"
> MediaType"File"
> VolSessionId=1
> VolSessionTime=1218720413
> VolFile=0-0
> VolBlock=217-431832
> fi=0x82360b0
> FileIndex=1-524

And as you say, this doesn't seem to be getting the second Volume.  Is it 
perhaps on the second Storage resource?

>
> > Also the following line from below:
> >  Aug 13 14:26:37  bacula-dir: bacula.example.com-dir JobId 15: Storage ""
> >
> > > not found, using Storage "0" from MediaType "File". Aug 13 14:26:37
> >
> > indicates that something has gone wrong.  Why is the storage name empty?
>
> I'm still getting this (though it is saying Storage "C" since I simplified
> my config). I don't know why it does it, as my configuration
> (above) seems to have the Storage set everywhere. Where is it reading it
> from at this stage?

Probably because you are using two different Storage resources, which probably 
won't work.  I say "probably" because I have over a period of time been 
adding code to permit much more flexibility in storage definitions, but it is 
not documented because it is only partially implemented, and hence will not 
work in *many* situations, such as very likely the case of Migration and 
Vbackup.

>
> Something else that is interesting is that the director status via bconsole
> shows this:
>
> Terminated Jobs:
>  JobId  Level    Files      Bytes   Status   Finished        Name
> ====================================================================
>      1  Full          0         0   Error    14-Aug-08 14:26 ABC
>      2  Full        524    346.2 K  OK       14-Aug-08 14:27 ABC
>      3  Incr          1    1.589 K  OK       14-Aug-08 14:27 ABC
>      4  Full        524    421.7 K  OK       14-Aug-08 14:28 ABC
>
> The first job went wrong because of my misconfiguration of the storage
> daemon that I then fixed, so don't worry about that.
>
> JobId 4 is the vbackup, and shows a much higher byte count than JobId 2,
> even though it has only copied the backup from JobId 2. Here is an 'ls -l'
> of the volumes on my disk:
>
> -rw-r----- 1 admin-bacula-sd admin-bacula-sd 431833 Aug 14 14:27
> backup-0001 -rw-r----- 1 admin-bacula-sd admin-bacula-sd   2305 Aug 14
> 14:27 backup-0002 -rw-r----- 1 admin-bacula-sd admin-bacula-sd 431833 Aug
> 14 14:28 backup-0003
>
> I also notice that a 'list pools' in bconsole shows that all the volumes
> have ended up in the "Normal" pool, when I was expecting the vbackup to end
> up in "Consolid".
>
> *list pools
> Automatically selected Catalog: MyCatalog
> Using Catalog "MyCatalog"
> +--------+----------------------------+---------+---------+----------+-----
>--------+
>
> | PoolId | Name                       | NumVols | MaxVols | PoolType |
> | LabelFormat |
>
> +--------+----------------------------+---------+---------+----------+-----
>--------+
>
> |      1 | Scratch                    |       0 |       0 | Backup   |
> | backup-     | 2 | Consolid                   |       0 |       0 | Backup
> |   | backup-     | 3 | Normal                     |       3 |       0 |
> | Backup   | backup-     |
>
> +--------+----------------------------+---------+---------+----------+-----
>--------+

Let's examine these last problems after you re-simplify down to a single 
Storage daemon -- hopefully they will go away.

Best regards,

Kern



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.