Subject | Re: [IB-Architect] Full and Differential Backup |
---|---|
Author | Jim Starkey |
Post date | 2000-06-23T15:47:45Z |
At 05:26 PM 6/23/00 +0200, Olivier Mascia wrote:
protocols used to the implement the standard API used by gbak were
designed for record by record interactivity between client and server
and not optimized for streaming very large quantities of undecipherable
gook. Gook is best delivered by moving van, not a shopping cart.
1. It makes it much faster to bring a backup on line.
2. It's vastly easier.
Skipping the indexes means that somebody is going to have to dummy
up index root pages as well as cope with a large number of AWOL
pages. If we get an incrementation backup out of this thread,
the cost is minor.
Jim Starkey
>Stand up the fellow, Olivier. What you meant to say was that the
>Dalton Calford wrote,
>
>| Using the gbak as a client would allow a backup to occur over the net
>using
>| standard IB protocals.
>
>I agree with you. That's why I announced the "color" first.
>Now, it may be a disadvantage or not. Depends on the needs of everybody.
>Byt the way, nothing, by design, would prevent to flow the output of my
>backup proposal through the network connection between the client and the
>server. Or to a tape drive... My original idea is that it *may* be quicker
>to do it locally, then why not retrieve a copy of the backup file.
>
protocols used to the implement the standard API used by gbak were
designed for record by record interactivity between client and server
and not optimized for streaming very large quantities of undecipherable
gook. Gook is best delivered by moving van, not a shopping cart.
>Code to detach a shadow should be very simple and no break anything.
>
>Indeed, that's true shadowing has details in common. But there are also
>differences. The backup does not require the 1 minute shutdown. That may be
>the whole difference for some needs. I would be happy the discuss possible
>shadowing extensions to achieve the same goals. If at all feasible, I would
>vote for something that build on existing engine technology.
>
>| Gbak does not copy the indexes or any other dynamic data. GbakSaving the indexes has two major advantages:
>recreates the indexes upon restore.
>
>Yes, knew that. The proposed behaviour is closer to shadows than to gbak as
>you very correctly stated. Maybe, if indexes are always stored on separate
>pages from pages where data lives, my scheme could be slightly updated to
>skip over index pages. But I have no idea of the real internals of ODS for
>now.
>
1. It makes it much faster to bring a backup on line.
2. It's vastly easier.
Skipping the indexes means that somebody is going to have to dummy
up index root pages as well as cope with a large number of AWOL
pages. If we get an incrementation backup out of this thread,
the cost is minor.
Jim Starkey