Remember Alexandre, GBAK (and Services API) are a DataPump-style backup,
diffent of NBAK (which AFAIR restores database pages instead of loginal
structure)
which makes me think: you tried that restore on a heavily fragmented
storage?

Since GBAK works as a datapump, certainly it makes the Server grows the
*.fdb file
so many times. Would be nice if we could (if it already doesn't
do that) specify an file size on restore and it could be created using
instant file instancing
(I know it have something to do with a volume operation, since the
service user
need to have disk volume operations' permission on Windows - MSSQL use that
and brings the restore multi GB time to a half - or less).



Em 19/04/2012 12:38, Alexandre Benson Smith escreveu:

>
> Em 19/4/2012 12:28, Carlos H. Cantu escreveu:
> > Sorry but the discussion is going "off-topic" for the original
> > question, that is: why backup/restore of blobs are so much slower
> > compared to non-blobs data. I'm also curious about this.
> >
> > Carlos
> > Firebird Performance in Detail - http://videos.firebirddevelopersday.com
> > www.firebirdnews.org - www.FireBase.com.br
> >
>
> I noted this slowness for some time, but never created a test case so it
> can be measured.
>
> I am sending a back-up to Dmitry Kuzmenko (as he asked for) so he could
> take a look.
>
> I really don't know what's happening, but it's strange to me.
>
> I think that a profilling of gbak and fb server process during the
> restore could show where the time is used and shed some light.
>
> see you !
>
>