Hello,
21.10.2007 23:22,, GDS.Marshall wrote::
> Hello Arno,
>
>> Hi,
>>
>> 21.10.2007 00:28,, GDS.Marshall wrote::
>>> Hello,
>>>
>>> I have looked through the archives and the documentation, but can not
>>> find
>>> an answer to my problem.
>> I think I know the answer, and am quite sure it is in the manual, too :-)
>>
>>> Using 2.2.4 (patched from sourceforge), I have the following pools
>>>
>>> Pool {
>>> Name = Weekly
>>> Pool Type = Backup
>>> Auto Prune = yes
>>> Volume Retention = 30 days
>>> Recycle = yes
>>> Recycle Oldest Volume = yes
>>> Cleaning Prefix = "CLN"
>>> }
>>>
>>> Pool {
>>> Name = Daily
>>> Pool Type = Backup
>>> Auto Prune = yes
>>> Volume Retention = 10 days
>>> Maximum Volumes = 10
>>> Recycle = yes
>>> Recycle Oldest Volume = yes
>>> Cleaning Prefix = "CLN"
>>> }
>>>
>>> The following job definition is used
>>> JobDefs {
>>> Name = "DailyJob"
>>> Type = "Backup"
>>> Level = "Incremental"
>>> Pool = "Daily"
>>> Full Backup Pool = "Weekly"
>>> FileSet = "Full Set"
>>> Messages = "Standard"
>>> Schedule = "Weekly Full"
>>> Storage = "Tape"
>>> Priority = 10
>>> Spool Data = Yes
>>> Spool Attributes = yes
>>> Maximum Concurrent Jobs = 20
>>> }
>>>
>>> The following schedule
>>> Schedule {
>>> Name = "Weekly Full"
>>> Run = Level=Full Pool=Weekly sat at 3:00
>>> Run = Level=Incremental Pool=Daily FullPool=Weekly mon-fri at 3:00
>>> }
>>>
>>> list media gives
>>> | 18 | CNI907 | Used | 1 | 23,790,348,288 |
>>> 23
>>> | 1,728,000 | 1 | 2 | 1 | DLT-V4 | 2007-10-20
>>> 21:19:37 |
>>>
>>> sql gives
>>> | MediaId | VolumeName | Slot | PoolId | MediaType | MediaTypeId |
>>> LabelType | FirstWritten | LastWritten | LabelDate
>>> | VolJobs | VolFiles | VolBlocks | VolMounts | VolBytes | VolParts |
>>> VolErrors | VolWrites | VolCapacityBytes | VolStatus | Enabled | Recycle
>>> |
>>> VolRetention | VolUseDuration | MaxVolJobs | MaxVolFiles | MaxVolBytes |
>> ^^^^^^^^^^^^^^
>>> InChanger | StorageId | DeviceId | MediaAddressing | VolReadTime |
>>> VolWriteTime | EndFile | EndBlock | LocationId | RecycleCount |
>>> InitialWrite | ScratchPoolId | RecyclePoolId | Comment |
>>> +---------+------------+------+--------+-----------+-------------+-----------+---------------------+---------------------+---------------------+---------+----------+-----------+-----------+-------------+----------+-----------+-----------+------------------+-----------+---------+---------+--------------+----------------+------------+-------------+-------------+-----------+-----------+----------+-----------------+-------------+--------------+---------+----------+------------+--------------+---------------------+---------------+---------------+---------+
>>> | 18 | CNI907 | 2 | 4 | DLT-V4 | 0 |
>>> 0 | 2007-10-20 19:48:00 | 2007-10-20 21:19:37 | 2007-10-20 19:51:50 |
>>> 9 | 23 | 368773 | 7 | 23790348288 | 0 |
>>> 0
>>> | 773429 | 0 | Used | 1 | 1 |
>>> 1728000 | 86400 | 0 | 0 | 0 |
>> ^^^^^
>>> 1 | 2 | 0 | 0 | 0 | 1333403394
>>> |
>>> 23 | 12273 | 0 | 4 | 0000-00-00 00:00:00 |
>>> 0 | 4 | NULL |
>>> +---------+------------+------+--------+-----------+-------------+-----------+---------------------+---------------------+---------------------+---------+----------+-----------+-----------+-------------+----------+-----------+-----------+------------------+-----------+---------+---------+--------------+----------------+------------+-------------+-------------+-----------+-----------+----------+-----------------+-------------+--------------+---------+----------+------------+--------------+---------------------+---------------+---------------+---------+
>>> 1 row in set (0.12 sec)
>>>
>>> In order to get more than one job to write to the same tape when doing a
>>> Level=Full, I have to update the volstatus to append by hand.
>> You've got a volume use duration set for this volume. This is probably
>> due to that volume being created with a pool definition containing
>> this clause, or by being updated manually to this.
> Yes, the use duration is set to 1 day. I want to be able to append to
> tapes all day. The FirstWritten date is not over 1 day, so under the
> circumstances, I would not have expected the volstatus to be changed.
Hmmm... good point. The fun with different time zones - I just used my
local time then and found that your use time was over. Probably it was
not when the job in question ran.
Could you post the output from 'llist volume=CNI907' for better
readability, and search through your message mails or log file for
events regarding this volume?
There should be some line explaining why this volume was marked as used...
>
>
>> You can simply use the 'update volume' command to remove this setting.
>>
>> And keep in mind that the pool definition is simply the template used
>> when creating new volumes, and is not applied to existing ones
>> automatically.
> I found that out the hard way a while back.
>
>
>>> If I have missed any information which would help solve the problem
>>> please
>>> let me know.
>> Everything in place now? :-)
> Unfortunatley not. I only ended up with even more google results from the
> mailing list :) I noted back in April Ralf Gross has a similar problem,
> but I could not work out what the result was.
Well, that was 2.0.3, and the way recycling is done has been changed a
lot in between... in short, Bacula is now much less aggressive when
trying to create usable volumes, and (should) only purge one volume at
a time. I assume that Ralfs problem vanished with a more recent version.
Also Ralf gave some indication that at least part of his problem might
have been caused by manually intervention, which makes it difficult to
recreate the exact problem.
Arno
>
>> Arno
>>
>>> For some reason, after each Level=Full job, the volume is marked Used
>>> and
>>> not Append. The Level=Incrementals work fine, setting it to Append.
>>>
>>> What have I set wrong?
>>>
> Many thanks,
>
> Spencer
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
--
Arno Lehmann
IT-Service Lehmann
www.its-lehmann.de
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
