Hello Sergio,
Yes, it has all signs of being a hardware error.
A critical target error with a sector address that is reasonable
for Bacula's byte address sounds to me like the OS had a write
error so the disk could not be read correctly by Bacula. The time
> Thanks Kern and Wanderlei,
Hello, Sergio,
> I've tried bls and I get:
> 06-Jul 11:48 bls JobId 0: Error: block.c:429 Read error on fd=3 at file:blk
> 0:397845547 on device "WStorage2" (/backup/external/2week). ERR=Input/output
> error.
> 06-Jul 11:48 bls JobId 0: Error: read_records.c:124
Thanks Kern and Wanderlei,
I've tried bls and I get:
06-Jul 11:48 bls JobId 0: Error: block.c:429 Read error on fd=3 at file:blk
0:397845547 on device "WStorage2" (/backup/external/2week).
ERR=Input/output error.
06-Jul 11:48 bls JobId 0: Error: read_records.c:124 block.c:429 Read error
on fd=3
Yes, Bacula is telling you that it is a disk I/O error.
I suggest you check your kernel log. This looks like a hardware
I/O error. If you find something in your kernel log, you should
check your disk drive very carefully, it may be going bad. If
there are
Hello Sergio
Probably you have some error in the volume.
You can try BLS and BEXTRACT to try to restore some data from the volume.
In the shell command line:
Syntax
bls -c /etc/bacula/bacula-sd.conf -V Volume-0001 /path/for/storage
bextract -c /etc/bacula/bacula-sd.conf -V Volume-0001
Hi,
When I run restore, I have the following errors:
04-Jul 13:39 bacula-sd JobId 2094: Error: block.c:429 Read error on fd=7 at
file:blk 0:397845547 on device "WStorage2" (/backup/external/2week).
ERR=Input/output error.
04-Jul 13:39 bacula-sd JobId 2094: Error: read_records.c:124 block.c:429
Hello,
I am attempting to perform a test restore using bacula however the job
is failing to restore symlinks which are backed up the volume.
Here is the error from the console.
13-Feb 10:53 rt01.example.com JobId 8339: Error: create_file.c:305 Could
not symlink
Below is the console log from my failing restore job. As you can see, the
number of files restored is WAY low. I'm trying to figure out how to get
what I can out of this restore.
I've done small restores before, a file or two, a even a small directory.
This is the first time I've had to
Roland Roberts wrote:
Below is the console log from my failing restore job. As you can see, the
number of files restored is WAY low. I'm trying to figure out how to get
what I can out of this restore.
I've done small restores before, a file or two, a even a small directory.
This is the
Roland Roberts wrote:
It would appear the problem is in the backend with quoting file names. I
have some configuration files that were created via a Java webstart task.
Who cares? Well, they are arguably misconfigured 'cause they create their
config files as c:\jobwatch.properties which
-users
Subject: Re: [Bacula-users] Restore errors
Hi Mair,
did you tried with a dbcheck ?
(dbcheck -c /path/to/bacula-dir.conf ; Toggle modify database flag ; 16)
All (3-15))
I had also a huge difference between files expected and files restored,
but the operation above fixed that ...
Regards
On 7/31/07, Mair Wolfgang-awm013 [EMAIL PROTECTED] wrote:
I started the DB check yesterday morning. It is still running. How long
does this usually take? Or am I doing something wrong?
This depends on how big your database, what type of database and if it
is properly indexed.
:[EMAIL PROTECTED]
MWa Sent: Monday, July 30, 2007 10:22
MWa To: Mair Wolfgang-awm013
MWa Cc: Doytchin Spiridonov; bacula-users
MWa Subject: Re: [Bacula-users] Restore errors
MWa Hi Mair,
MWa did you tried with a dbcheck ?
MWa (dbcheck -c /path/to/bacula-dir.conf ; Toggle modify database flag ; 16
porsche-dir: No Files found to prune.
27-Jul 11:28 porsche-dir: End auto prune.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Doytchin Spiridonov
Sent: Saturday, July 28, 2007 02:02
To: bacula-users
Subject: Re: [Bacula-users] Restore errors
Hello
] On Behalf Of
Doytchin Spiridonov
Sent: Saturday, July 28, 2007 02:02
To: bacula-users
Subject: Re: [Bacula-users] Restore errors
Hello,
just to note that several days after a full backup and incremental
bacpus, restores are OK, which again proves that the problem was caused
by running
-users] Restore errors
MWa Hello,
MWa just to note that several days after a full backup and incremental
MWa bacpus, restores are OK, which again proves that the problem was caused
MWa by running concurrent jobs.
MWa Wolfgang do you have the same results?
MWa Regards
MWa Wednesday, July 25
-users
MWa Subject: Re: [Bacula-users] Restore errors
MWa Hello,
MWa just to note that several days after a full backup and incremental
MWa bacpus, restores are OK, which again proves that the problem was caused
MWa by running concurrent jobs.
MWa Wolfgang do you have the same results
Hello,
just to note that several days after a full backup and incremental
bacpus, restores are OK, which again proves that the problem was
caused by running concurrent jobs.
Wolfgang do you have the same results?
Regards
Wednesday, July 25, 2007, 8:12:25 PM:
DS Hello,
DS 2nd day w/o
Steen wrote:
Hello,
just wondering from the sideline here:
On Tuesday 24 July 2007 07:28:48 Doytchin Spiridonov wrote:
1. some static files (i.e. not log files!) are restored with wrong
(always larger) size, while first N bytes match, and the rest is
filled with a part of another file
Hello,
Thursday, July 26, 2007, 7:38:43 PM:
S Hello,
S just wondering from the sideline here:
The file can be restored correctly if marked alone
S doesn't his prove that the relevant catalog data for the file is OK?
This probably means that the problem is with positioning inside
volumes?
Hello,
just wondering from the sideline here:
On Tuesday 24 July 2007 07:28:48 Doytchin Spiridonov wrote:
1. some static files (i.e. not log files!) are restored with wrong
(always larger) size, while first N bytes match, and the rest is
filled with a part of another file (not sure if this is
Hello,
2nd day w/o concurrent jobs: we have 1xFULL and 1xINCREMENTAL for all
clients.
Restore OK of all jobs.
Seems this (concurrent jobs) is the problem.
Regards.
Tuesday, July 24, 2007, 9:57:35 PM:
DS I don't have any other ideas to check with to provide more cases. It's
DS developers
the restore will work out fine now with this setting. I'll keep you
updated.
Regards
Wolfgang
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doytchin
Spiridonov
Sent: Tuesday, July 24, 2007 07:29
To: bacula-users
Subject: Re: [Bacula-users] Restore errors
On 7/24/07, Mair Wolfgang-awm013 [EMAIL PROTECTED] wrote:
Hello,
This is exactly what I experienced last week. I submitted this under the
subject: ' Restore Error of linux-install-fdFul'.
However, I didn't had the time yet to track this as much down as Doytchin
did. Great work!
This
Doytchin Spiridonov wrote:
Hello,
done. Found where is the problem after some more tests (and once again
it is not in our hadrware or OS or broken things). It is where I
initially suggested - the concurrent jobs.
So you can reliably reproduce the problem now? Excellent!
After the first
Media Type = File
Maximum Concurrent Jobs = 1
}
-Original Message-
From: John Drescher [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 24, 2007 13:00
To: Mair Wolfgang-awm013
Cc: Doytchin Spiridonov; bacula-users
Subject: Re: [Bacula-users] Restore errors
On 7/24/07, Mair Wolfgang-awm013
Mair Wolfgang-awm013 wrote:
Spooling? Does this also apply if my backup goes directly to files?
It would in this case, yes. With spooling, the data goes to the spooling file
first, and is then unspooled in chunks. Without spooling, all of the data
from the multiple jobs goes straight to the
Hello,
Tuesday, July 24, 2007, 2:00:43 PM:
FS Okay, so it looks like you can reproduce the symptoms just with multiple
FS concurrent jobs, regardless of the gzip settings.
I am sure the file/dirs backed up are important! I bet developers are
tested enough concurrent jobs but if they didn't
Hello,
Tuesday, July 24, 2007, 2:00:43 PM:
FS Also, it's been suggested that you try turning on spooling. Have you done
so?
Good news (or bad, who knows) enabled spooling (Maximum Job Spool Size
= 500m) performed the same and AGAIN the first job I tested to restore
~44K files are missing:
Just to say that the difference problem I had between Files Expected
and Files Restored has been resolved with a $ dbcheck
I don't understand why my database had inconsistencies (as I never had
any hard reboot, electric cut or such) ... should dbcheck be executed at
regular interval ?
On Tue,
Hello,
the last 2 tests:
Tuesday, July 24, 2007, 2:00:43 PM:
FS Actually, that gives me another idea. While I've never used it myself, you
FS may be able to get more details by running some jobs with strict mode turned
FS on on your mysql catalog.
FS
Hello,
trying to identify a bug in bacula and/or our system setup.
Is there anyone that on restore had errors like this:
Error: attribs.c:410 File size of restored file
/home/bacula/res/b3/usr/src/redhat/RPMS/i686/glibc-2.2.5-44.i686.rpm
not correct. Original 3826291, restored 10620921.
- the
Doytchin Spiridonov wrote:
Hello,
trying to identify a bug in bacula and/or our system setup.
Is there anyone that on restore had errors like this:
Error: attribs.c:410 File size of restored file
/home/bacula/res/b3/usr/src/redhat/RPMS/i686/glibc-2.2.5-44.i686.rpm
not correct. Original
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Doytchin Spiridonov wrote:
Hello,
trying to identify a bug in bacula and/or our system setup.
Is there anyone that on restore had errors like this:
Error: attribs.c:410 File size of restored file
On 23 Jul 2007 at 14:03, Ryan Novosielski wrote:
This has been brought up several times within the last week, but never
with the explanation and examination. I wonder if some of the other
who have experienced it (I do not know their names -- hopefully they
can chime in) can do the same thing
Hello,
I've filed this as a bug, but while Kern couldn't reproduce it he gave
up. So let us find here what could be the problem. There are actually
two problems, they could be linked.
Here is the history:
Initially we were using 2.0.3. Running backups for several weeks I
wanted to restore a file
Hello Dan,
Monday, July 23, 2007, 9:35:05 PM:
DL Devel is aware of the issue as it was originally raised in the bug
DL tracking system. The consensus was it is not a bug, or more
DL correctly, there was no information supplied which permitted
DL reproduction of the bug. If we can't
Hello,
I forgot to mention something very IMPORTANT: I discovered that in
*all* of such cases (restored files with larger size), if we don't
perform full restore, but restore a SINGLE file, it is restored OK
with *correct* size and content. It is OK even if we restore the
directory where it is
sometimes not all files are restored, but tens of thousands are
missing, an example:
Files Expected: 190,718
Files Restored: 166,097
This happens more often (~one case per 2 jobs).
Just to say that I have the case too every time I restore, but I think
you can ignore it.
Hello,
no, probably you didn't found which are the missing files. After we
restore we compare the restored files with original. The conclusion is
that there are really missing files! (As I mentioned those are not
hardlinks, sockets, etc - in a test we had missing /home/ directory
and all files in
On 23 Jul 2007 at 21:57, Doytchin Spiridonov wrote:
Hello Dan,
Monday, July 23, 2007, 9:35:05 PM:
DL Devel is aware of the issue as it was originally raised in the bug
DL tracking system. The consensus was it is not a bug, or more
DL correctly, there was no information supplied
On 23 Jul 2007 at 21:57, Doytchin Spiridonov wrote:
Hello,
I've filed this as a bug, but while Kern couldn't reproduce it he gave
up. So let us find here what could be the problem. There are actually
two problems, they could be linked.
Please. If anyone can solve the issue given what you
Hello,
don't get me wrong, I know pretty well that nothing can be done there
until you have a clean example. But having in mind that these errors
hapen in 1 per 4 million files it also would be hard to isolate the
case where this happens. The fact is that it happens pretty often and
as I said we
Hello,
Tuesday, July 24, 2007, 12:15:37 AM:
DL Someone sugested you verify your filesystem (e.g. fsck). Have you
DL done that?
Yes:
FS The first thing that I would try is unmounting the filesystem and
performing a
FS full fsck on it, to rule out filesystem corruption.
1. unmounted and
Hello,
Monday, July 23, 2007, 9:02:21 PM:
FS The first thing that I would try is unmounting the filesystem and
performing a
FS full fsck on it, to rule out filesystem corruption.
not a problem with the FS or disks, checked that.
Checked the logical content of the volumes as well (bls -k -v)
Doytchin Spiridonov wrote:
Hello,
Monday, July 23, 2007, 9:02:21 PM:
FS The first thing that I would try is unmounting the filesystem and
performing a
FS full fsck on it, to rule out filesystem corruption.
not a problem with the FS or disks, checked that.
Checked the logical
Hello,
Tuesday, July 24, 2007, 12:15:37 AM:
DL On 23 Jul 2007 at 21:57, Doytchin Spiridonov wrote:
DL Test the backups. Backup one file. Restore. Backup N files.
DL restore. Backup N directories, restore. Find a simple and
DL reproducible situation which demonstrates the problem.
Hello,
Tuesday, July 24, 2007, 2:25:44 AM:
FS Doytchin Spiridonov wrote:
Hello,
Monday, July 23, 2007, 9:02:21 PM:
FS The first thing that I would try is unmounting the filesystem and
performing a
FS full fsck on it, to rule out filesystem corruption.
not a problem with the FS or
Hello,
done. Found where is the problem after some more tests (and once again
it is not in our hadrware or OS or broken things). It is where I
initially suggested - the concurrent jobs.
After the first (and native configuration) we used (concurrent jobs,
with gzip) we tested the following:
1.
On Friday 21 October 2005 21:11, Martin Simmons wrote:
On Thu, 20 Oct 2005 16:29:17 +1000, Craig Holyoak
[EMAIL PROTECTED] said:
Craig On Wed, 2005-10-19 at 11:17 +0100, Martin Simmons wrote:=20
On Wed, 19 Oct 2005 12:08:24 +1000, Craig Holyoak
[EMAIL PROTECTED] said:
Craig
On Thu, 20 Oct 2005 16:29:17 +1000, Craig Holyoak [EMAIL PROTECTED]
said:
Craig On Wed, 2005-10-19 at 11:17 +0100, Martin Simmons wrote:=20
On Wed, 19 Oct 2005 12:08:24 +1000, Craig Holyoak [EMAIL PROTECTED]
said:
Craig I'm running bacula 1.36.2 on Debian stable. Whenever I try to
On Fri, 2005-10-21 at 20:11 +0100, Martin Simmons wrote:
On Thu, 20 Oct 2005 16:29:17 +1000, Craig Holyoak [EMAIL PROTECTED]
said:
Craig On Wed, 2005-10-19 at 11:17 +0100, Martin Simmons wrote:=20
On Wed, 19 Oct 2005 12:08:24 +1000, Craig Holyoak [EMAIL
PROTECTED] said:
On Wed, 2005-10-19 at 11:17 +0100, Martin Simmons wrote:
On Wed, 19 Oct 2005 12:08:24 +1000, Craig Holyoak [EMAIL PROTECTED]
said:
Craig I'm running bacula 1.36.2 on Debian stable. Whenever I try to run a
restore
Craig job, it fails with:
Craig 19-Oct 11:29 helmsdeep: Start
On Wed, 19 Oct 2005 12:08:24 +1000, Craig Holyoak [EMAIL PROTECTED]
said:
Craig I'm running bacula 1.36.2 on Debian stable. Whenever I try to run a
restore
Craig job, it fails with:
Craig 19-Oct 11:29 helmsdeep: Start Restore Job Restore.2005-10-19_11.29.50
Craig 19-Oct 11:29
I'm running bacula 1.36.2 on Debian stable. Whenever I try to run a restore
job, it fails with:
19-Oct 11:29 helmsdeep: Start Restore Job Restore.2005-10-19_11.29.50
19-Oct 11:29 newman: Restore.2005-10-19_11.29.50 Fatal error: Could not
55 matches
Mail list logo
