On Wednesday 30 November 2005 10:11, Ferdinando Pasqualetti wrote: > 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.
OK. > > -------------------------------------------------------------------------- > 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] -- Best regards, Kern ("> /\ V_V ------------------------------------------------------- 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_idv37&alloc_id865&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
