I am sorry Kern, but by backup job was already recycled (I have no space for more than 3 full backups on the disk storage, and using incremental or differential changes only some percent of space, because the system contains mastly huge mail notes databases, which are changed continuously).
The restore was done to rebuild the system on bigger disks, and I am going to do the same operation tomorrow on the brother cluster system, so I can see if this problem comes again and apply your suggestions.

--------------------------------------------------------------------------
Ferdinando Pasqualetti
G.T.Dati srl
Tel. 0557310862 - 3356172731 - Fax 055720143




Kern Sibbald <[EMAIL PROTECTED]> wrote on 29/11/2005 22.11.05:

> Try putting the attached file in your scripts directory, then do in
> bconsole:
>
>    query
>    16
>    (jobid)
>    /uno/notesdata/ravarino/
>    mmonesi.nsf
>    (jobid)
>    (jobid)
>    (jobid)
>
>
> where you replace (jobid) with the jobid of the backup
> job where /uno/notesdata/ravarino/mmonesi.nsf was saved
>
> Then send me the output. That will tell us where mmonesi.nsf was
> on the backup.
>
> On Monday 28 November 2005 16:00, Ferdinando Pasqualetti wrote:
> > Hello list,
> >
> > sorry I sent the original message with a wrong sender address, it is here
> > anyway. Again I was impressed by the restore performance during a massive
> > restore. Trying to restore single files  it seemed to me that positioning
> > performance in disk files was less efficient than using tapes. Doing
> > "status storage=.." during the restore it seems that positioning in the
> > volume is done by subsequent readings of data blocks, while on a tape this
> > is done by skip-files and or skip blocks. This could be kept unimportant
> > using small volume size (I remember a Kern advice about that), but I would
> > like to keep disk volume sizes in a 1:1 ratio with tape ones, in order to
> > move them if necessary. I know that on a disk file you cannot write EOF, as
> > on tapes, and probably disk media are considered tapes that cannot skip
> > files or blocks, but tapes anyway, so they cannot fseek, but a
> > consideration about this behavior I think should be done.
> >
> > Regards,
> >  
> > --------------------------------------------------------------------------
> >  Ferdinando Pasqualetti
> >  G.T.Dati srl
> >  Tel. 0557310862 - 3356172731 - Fax 055720143
> >
> > [EMAIL PROTECTED] wrote on 28/11/2005 11.21.42:
> >  > Hello list,
> >  > this is to show the (for me) impressive throughput in restoring
> >  > files. Client and server are two HP Proliant G3 with 3 Gb RAM and
> >  > mirrored SCSI disks, connected with a gigabit link.
> >  > There is a problem in restoring one file (I think it is the last
> >  > one), which resulted truncated. I tried to repeat the restore for
> >  > that file only, but I got the same problem.
> >  > Happy backup and restore to everybody and many thanks to people
> >  > providing this exceptional tool.
> >  >
> >  >
> >  > 26-Nov 12:31 domino2: RestoreFiles.2005-11-26_11.00.27 Error:
> >  > attribs.c:339 File size of restored file
> >  > /uno/notesdata/ravarino/mmonesi.nsf not correct. Original
> >  > 1132986368, restored 715489280.
> >  > 26-Nov 12:31 bacula-sd: End of all volumes.
> >  > 26-Nov 12:31 bacula-dir: RestoreFiles.2005-11-26_11.00.27 Error:
> >  > Bacula 1.36.3 (22Apr05): 26-Nov-2005 12:31:04
> >  >  JobId:                  3060
> >  >  Job:                    RestoreFiles.2005-11-26_11.00.27
> >  >  Client:                 domino2
> >  >  Start time:             26-Nov-2005 11:00:29
> >  >  End time:               26-Nov-2005 12:31:04
> >  >  Files Expected:         8,510
> >  >  Files Restored:         8,510
> >  >  Bytes Restored:         255,108,659,471
> >  >  Rate:                   46938.1 KB/s
> >  >  FD Errors:              2
> >  >  FD termination status:  Error
> >  >  SD termination status:  OK
> >  >  Termination:            *** Restore Error ***
> >  >
> >  > Ferdinando Pasqualetti
> >  > ------------------------------------------------------- This SF.net
> >  > email is sponsored by: Splunk Inc. Do you grep through log files for
> >  > problems? Stop! Download the new AJAX search engine that makes
> >  > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> >  > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> >  > _______________________________________________ Bacula-users mailing
> >  > list Bacula-users@lists.sourceforge.net https://lists.sourceforge.
> >  > net/lists/listinfo/bacula-users
> >  > ------------------------------------------------------- This SF.net
> >  > email is sponsored by: Splunk Inc. Do you grep through log files for
> >  > problems? Stop! Download the new AJAX search engine that makes searching
> >  > your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> >  > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> >  > _______________________________________________ Bacula-users mailing
> >  > list Bacula-users@lists.sourceforge.net
> >  > https://lists.sourceforge.net/lists/listinfo/bacula-users
>
> --
> Best regards,
>
> Kern
>
>   (">
>   /\
>   V_V
> [attachment "query.sql" deleted by Ferdinando Pasqualetti/San
> Lazzaro/Conserve Italia]
------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to