Menu
▾
▴
Re: [Bacula-users] Continue with 1.32c and a full backup is written ...
|
From: Kern S. <ke...@si...> - 2003-10-31 19:59:31
|
On Fri, 2003-10-31 at 17:46, Lars K=F6ller wrote:
> Hi!
>=20
> In reply to Kern Sibbald who wrote:
>=20
> >Could you run the following Console commands for me, and perhaps
> >we can figure out what has gone wrong.
> >
> > ./console
> > select * from FileSet where FileSet=3D'Full Set door';
> > select JobId, FileSetId, ClientId, StartTime, Level,=20
> > JobStatus from Job where Name=3D'FullDiffIncr-door';
>=20
> Kern, here are the database output.
>=20
> Enter SQL query: select * from FileSet where FileSet=3D'Full Set door';
> +-----------+---------------+------------------------+-----------------=
----+
> | FileSetId | FileSet | MD5 | CreateTime =
|
> +-----------+---------------+------------------------+-----------------=
----+
> | 3 | Full Set door | 0DF8P7suRW+HW5/IU/+RxA | 2003-10-11 21:49=
:40 |
> | 7 | Full Set door | QU/bY4/Ye+gvFxoWxHQmIB | 2003-10-29 22:26=
:28 |
> +-----------+---------------+------------------------+-----------------=
----+
I see the problem already. For some reason, the FileSet changed on
the 29th, which means it *should* have done a Full save on that day
rather than the Incremental. That's probably a bug.=20
However, I'd like to double check the data before drawing final
conclusions.
>=20
>=20
> Enter SQL query: select JobId, FileSetId, ClientId, StartTime, Level, J=
obStatus from Job where Name=3D'FullDiffIncr-door';
> +-------+-----------+----------+---------------------+-------+---------=
--+
> | JobId | FileSetId | ClientId | StartTime | Level | JobStatu=
s |
> +-------+-----------+----------+---------------------+-------+---------=
--+
> | 4 | 3 | 2 | 2003-10-11 21:49:40 | F | T =
|
> | 7 | 3 | 2 | 2003-10-12 21:50:08 | D | T =
|
> | 12 | 3 | 2 | 2003-10-13 21:59:05 | I | T =
|
> | 15 | 3 | 2 | 2003-10-14 21:47:01 | I | T =
|
> | 18 | 3 | 2 | 2003-10-15 21:56:55 | I | T =
|
> | 21 | 3 | 2 | 2003-10-16 21:57:34 | I | T =
|
> | 25 | 3 | 2 | 2003-10-17 21:58:48 | I | T =
|
> | 28 | 3 | 2 | 2003-10-18 21:56:33 | I | T =
|
> | 31 | 3 | 2 | 2003-10-19 22:15:00 | D | T =
|
> | 36 | 3 | 2 | 2003-10-20 22:03:07 | I | T =
|
> | 39 | 3 | 2 | 2003-10-21 21:47:35 | I | T =
|
> | 42 | 3 | 2 | 2003-10-22 22:06:47 | I | T =
|
> | 45 | 3 | 2 | 2003-10-23 22:42:16 | I | T =
|
> | 48 | 3 | 2 | 2003-10-24 22:01:45 | I | T =
|
> | 51 | 3 | 2 | 2003-10-25 21:55:32 | I | T =
|
> | 54 | 3 | 2 | 2003-10-26 21:45:08 | D | T =
|
> | 61 | 3 | 2 | 2003-10-27 22:06:02 | I | T =
|
> | 64 | 3 | 2 | 2003-10-28 21:46:19 | I | T =
|
> | 67 | 7 | 2 | 2003-10-29 22:26:28 | I | T =
|
> +-------+-----------+----------+---------------------+-------+---------=
--+
>=20
>=20
> Please can you give me a hint how to "free" the occupied space on the=20
> tape? I've canceld the job (which was waiting for an additional=20
> volume). And purge the last written volume-102)
Currently, there is no way to truncate the tape without doing some
"manual" work, including moving to the right file and writing an
EOF. I have never thought about doing this before -- I'm going to
note it for a possible future project.
Your best bet would be to examine all the data on the tape, and
then purge the tape, delete the jobs that were on the tape,
and do a proper backup of them. If you really want to try
to truncate the tape, let me know and I'll tell you what steps
you will need to take.
>=20
> +---------+------------+-----------+-----------+-------------+---------=
------------+--------------+---------+------+
> | MediaId | VolumeName | MediaType | VolStatus | VolBytes | LastWrit=
ten | VolRetention | Recycle | Slot |
> +---------+------------+-----------+-----------+-------------+---------=
------------+--------------+---------+------+
> | 5 | Volume-100 | AIT-2 | Full | 38015394006 | 2003-10-=
12 01:45:43 | 6048000 | 1 | 9 |
> | 6 | Volume-101 | AIT-2 | Full | 42318633141 | 2003-10-=
30 22:41:45 | 6048000 | 1 | 10 |
> | 7 | Volume-102 | AIT-2 | Purged | 37677776950 | 2003-10-=
31 02:28:00 | 6048000 | 1 | 11 |
> +---------+------------+-----------+-----------+-------------+---------=
------------+--------------+---------+------+
>=20
> However, how can I free the approx 10GB on volume-101 so the next=20
> incremental backup is written to it.
See above.
>=20
> If I have to write a full backup it should be gone to the medium or=20
> long pool.
I suspect that the easiest thing to do at this point is to
do a Full save, because now that the FileSet has changed, Bacula
is going to insist on a Full backup.
>=20
> Another question: When I observe my Qualstar 4210 (with=20
> SONY SDX-500C AIT2 drives) I notice you skip forward in 1GB steps. The=20
> tape seems to stop a short time, and than the next fsf takes place. I=20
> think it would be much faster to do a "mf fsf 24". Is there a special=20
> reason to go step by step with fsf?
Yes, when I was first dealing with tapes, I found the only 100% reliable
method of forward spacing more than one file was to fsf 1, read a
record, fsf 1, ... which is what you noticed. I noticed the same thing
you did a couple of weeks ago, and I'm planning in 1.33 to change
the code to do a fsf 24 as you and I would like it to do, and add
a configuration parameter that reverts to the old way for those
tape drives that don't work properly.
>=20
> Please can you add the above lib/tapes to the documentation?
Yes, of course, just to be sure I understand, is the Qualstar 4210
an autochanger? If so, what OS are you using it on, how many tapes
does it hold, and what is the capacity of the tapes, who
manufactures it, and how are the Sony drives related to the Qualstar?
I'll give a definitive answer on the Incremental/Full save problem
later tonight or tomorrow.
>=20
> Many thanks and best regards
>=20
> Lars
|