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 block
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 a
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 no
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 /path/fo
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
R
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 /storage/home/55/etc/rc.d/rc4.d/S2
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" whi
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 t
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 restore
ng-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)
MWa> All (3-15))
MWa> I had also a huge diffe
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.
-
-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
prinz-fd
> MWa> Start time: 27-Jul-2007 11:07:05
> MWa> End time: 27-Jul-2007 11:28:34
> MWa> Files Expected: 303,761
> MWa> Files Restored: 301,923
> MWa> Bytes Restored: 27,412,500,483
> MWa>
: 301,923
MWa> Bytes Restored: 27,412,500,483
MWa> Rate: 21266.5 KB/s
MWa> FD Errors: 7
MWa> FD termination status: Error
MWa> SD termination status: OK
MWa> Termination:*** Restore Error ***
MWa> 27-Jul 11:28 p
nz-fd
> Start time: 27-Jul-2007 11:07:05
> End time: 27-Jul-2007 11:28:34
> Files Expected: 303,761
> Files Restored: 301,923
> Bytes Restored: 27,412,500,483
> Rate: 21266.5 KB/s
> FD Errors:
11:28 porsche-dir: Begin pruning Files.
27-Jul 11:28 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-use
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 concur
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?
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 anoth
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
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 tu
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> http://dev.mysql.com/doc/refman/5.0/en
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,
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:
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 ca
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 v
ileStorage
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 Wolfg
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 fi
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!
>
complete.
Hopefully 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:
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. co
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 p
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.
Te
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
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)
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. unmou
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 a
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
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 sup
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
> 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,
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 (wi
Hi,
23.07.2007 20:57,, Doytchin Spiridonov wrote::
> Hello,
...
> What are our future tests:
> 1. we will do the same (concurrent jobs) but w.o using GZIP
> 2. if it happens again we will set max jobs to 1 so every job is run
> alone. Because when testing AFAIR we didn't get errors when we run
>
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 repr
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
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 thi
-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
> /home/bacula/res/b3/usr/src/redhat/RP
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.
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 f
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
> >> > <
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
> P
> 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 st
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 1
> 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> 1
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
cre
Hi
Can anyone shed light on the following restore errors:-
13-May 16:20 temp-ns-fd: RestoreFiles.2005-05-13_15.04.47 Error: attribs.c:339
File size of restored file /tmp/bacula-restores/usr/home/dns/logs/dns_query.log
not correct. Original 15190023, restored 15195134.
13-May 16:20 ethanol.tcm.gma
Hi All;
I'm getting a lot of FD errors while testing a restore, I am not sure
what is causing them.
- testing a bare metal recovery
- rebuild a catalog from a volume on a dev server.
- did not have a bootstrap file
- all the files were restored but about 1/3 were reported as being the
incorrect s
58 matches
Mail list logo
