Re: **Possibile SPAM**Re: **Possibile SPAM**[Bacula-users] Restore files

[Ferdinando Pasqualetti]

Hi Kern,
I should have thought that some practical problem was forcing to use read blocks. Maybe it is a silly idea, but do you think volumes could be matched with subdirs in disk storage and files inside them matched with files in tape volumes?
I imagine this would be an enormous (and tedious) work, but I would like to know if this could be implemented.

Thanks for your availability in our discussions, even if these are not always so useful.

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




[EMAIL PROTECTED] wrote on 28/11/2005 17.08.42:

> 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.
>
> I have worked on disk seeking several times, and each time, there is some
> silly regression test that failes.  So, I now await a time when I have
> nothing else to do (maybe in a few years) or for a patch the code is all
> implemented, it is just a matter of finding the *tiny* but important reason
> why it fails in some exceptional cases ...
>
> >
> > 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
>
>
> -------------------------------------------------------
> 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
>
------------------------------------------------------- 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