|
[Bacula-users] Bacula Catalog Corruption
2008-12-01 02:00:54
Dear Bacula Users,
Sorry, this is lengthy. I have
several questions. Any question answered is much appreciated. :)
I am now running bacula 2.4.2 (made
from source) and mysql 5.0.24-standard on RHEL4 (64 bit)
I use bacula for archiving - ie. once-only,
keep-forever backups of large files. It's particularly useful to
have a catalog with a record of what is on my tapes, since I'm already
up to 138 SDLT300/600's, and bscanning the lot takes a very long time.
(I speak from repeated experience - see below)
Previously I ran bacula-mysql 2.0.3-1
(rpm) and had the following problems:
A couple of times I have come back to
restore something, and discovered that bacula's catalog has been corrupted
or lost some of its data, *sometime*. I have never worked out when
or how. The File table seems to be partly or lost; I'm not sure whether
that is the only one.
Last time it happened, bscan of the
lost tapes was an adequate (but tedious) method for re-filling the catalog.
This time, I'm finding some tapes will not "re-fill": I
bscan the tape, and can see the tape contents in a mysql query, but bacula
restore still refuses to believe it has a copy of the data.
Example:
mysql> select JobMediaId,File.JobId,Path.Path,Filename.Name,Media.VolumeName,JobMedia.StartFile,JobMedia.StartBlock
from File,Path,Filename,Media,JobMedia where JobMedia.JobId = 532 and JobMedia.MediaId
= Media.MediaId and JobMedia.JobId = File.JobId and File.PathId = Path.PathId
and File.FilenameId = Filename.FilenameId;
+------------+-------+-----------------------------------+----------------------------------+------------+-----------+------------+
| JobMediaId | JobId | Path
| Name
| VolumeName | StartFile | StartBlock
|
+------------+-------+-----------------------------------+----------------------------------+------------+-----------+------------+
| 37076 |
532 | /data/tapes/reuters_raw/tape2228/ |
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2228/ |
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2228/ | daily_tmsa-21jul2008.dat.gz
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2228/ | daily_tmsa-21jul2008.dat.gz
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2228/ | daily_tmsa-21jul2008.dat.gz.size
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2228/ | daily_tmsa-21jul2008.dat.gz.size
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2231/ |
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2231/ |
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2231/ | daily_tmsa-25jul2008.dat.gz.size
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2231/ | daily_tmsa-25jul2008.dat.gz.size
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2231/ | daily_tmsa-25jul2008.dat.gz
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2231/ | daily_tmsa-25jul2008.dat.gz
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2230/ | daily_tmsb-24jul2008.dat.gz.size
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2230/ | daily_tmsb-24jul2008.dat.gz.size
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2230/ | daily_tmsb-24jul2008.dat.gz
| RRAW118 | 0 |
0 |
| 37076 |
532 | /data/tapes/reuters_raw/tape2230/ | daily_tmsb-24jul2008.dat.gz
| RRAW118 | 0 |
0 |
| 33199 |
532 | /data/tapes/reuters_raw/tape2228/ |
| RRAW118 | 124 |
0 |
| 33199 |
532 | /data/tapes/reuters_raw/tape2228/ |
| RRAW118 | 124 |
0 |
| 33199 |
532 | /data/tapes/reuters_raw/tape2228/ | daily_tmsa-21jul2008.dat.gz
| RRAW118 | 124 |
0 |
| 33199 |
532 | /data/tapes/reuters_raw/tape2228/ | daily_tmsa-21jul2008.dat.gz
| RRAW118 | 124 |
0 |
...
a) lots of repetition - is this
normal? could it be due to bscanning the same tape 2-3 times?
...
bconsole:
*restore
...
7: Enter a list
of files to restore
...
Defined Clients:
...
3: tapepc-fd
...
Enter full filename: /data/tapes/reuters_raw/tape2231/daily_tmsa-25jul2008.dat.gz
No database record found for: /data/tapes/reuters_raw/tape2231/daily_tmsa-25jul2008.dat.gz
Here is my bscan line:
bscan -c /etc/bacula/bacula-sd.conf
-r -v -m -s -P xxxxxxx -V RRAW119 /dev/nst1
A quick search in bacula's archives
found me Issue ID 1034: Temporary MySQL
table 'batch' disappears if MySQL connection times out
which sounds like it might be related
to my problem.
b) Does anyone know what caused
this problem, or in fact exactly what my problem was?
c) I installed the 2.4.2 code,
and haven't seen the problem re-occur. Can I be confident that it
was fixed sometime before 2.4.2?
Thanks for any help
Glen
--
Glen Davison
davo AT sirca.org DOT au
SIRCA Pty Ltd
Ph (02) 9236 9133-------------------------------------------------------------------------
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-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> |
- [Bacula-users] Bacula Catalog Corruption,
Glen Davison <=
|
|
|
