Subject | Re: [firebird-support] confiable backup? |
---|---|
Author | Artur Anjos |
Post date | 2003-06-24T10:29:23Z |
Hi Daniel,
Maybe we should distinguish in two parts. :-)
1) For now
The only way to test if you have a reliable backup it's to restore it. No
other way can guarantee you that you have a reliable backup.
2) What it should be.
Yes, it should be different. At the time we have a backup, it should be
reliable and 'restorable'. That's why we do backups, anyway.
I agree with you in everything. And more - for automatize backups we need
more info (or better info) from gbak, for example.
[ I'm a backup paranoic. I already spend a lot of time with GBak. With
version 1.5 restore times speed up, so I have a client that I use 1.0 in
production, and use 1.5 just to do the restore cycle to guarantee the gbak
procedure. ]
Another option for doing backups is to copy the all database file. For non
24/7 databases, we can always shut down the Firebird server, copy the file,
and bring Firebird Server up again. Even on 24/7 databases I think that this
will be an option: stopping the database for a few minutes (measuring the
benefficts to have a copy of the database against the time the database is
not available).
If I'm not wrong, we already have a sponsor to improve backups. Sean was
quite commited on this in Fulda, and we discuss it many times, at sessions
and at drinks. Nickolay could bring more info to this, but the all ideia is
to freeze the database file in time, and make backups of datapages instead
of tables. At the meantime, all database changes are written on another
file. After doing the backup, the second file is join to the the first one,
and this second file is deleted. This will be much faster, as you can
imagine.
And with a small ODS change, you will be abble to do a incremental backup,
using some kind of version numbers control.
Uf. Long email. Well, this was just to tell everybody that Backups is
something that we all know that should be improved, there are already some
nice plans to do it, and for now, if you want to make sure that you have a
reliable backup, just restore it on some place else. :-)
Artur
Maybe we should distinguish in two parts. :-)
1) For now
The only way to test if you have a reliable backup it's to restore it. No
other way can guarantee you that you have a reliable backup.
2) What it should be.
Yes, it should be different. At the time we have a backup, it should be
reliable and 'restorable'. That's why we do backups, anyway.
I agree with you in everything. And more - for automatize backups we need
more info (or better info) from gbak, for example.
[ I'm a backup paranoic. I already spend a lot of time with GBak. With
version 1.5 restore times speed up, so I have a client that I use 1.0 in
production, and use 1.5 just to do the restore cycle to guarantee the gbak
procedure. ]
Another option for doing backups is to copy the all database file. For non
24/7 databases, we can always shut down the Firebird server, copy the file,
and bring Firebird Server up again. Even on 24/7 databases I think that this
will be an option: stopping the database for a few minutes (measuring the
benefficts to have a copy of the database against the time the database is
not available).
If I'm not wrong, we already have a sponsor to improve backups. Sean was
quite commited on this in Fulda, and we discuss it many times, at sessions
and at drinks. Nickolay could bring more info to this, but the all ideia is
to freeze the database file in time, and make backups of datapages instead
of tables. At the meantime, all database changes are written on another
file. After doing the backup, the second file is join to the the first one,
and this second file is deleted. This will be much faster, as you can
imagine.
And with a small ODS change, you will be abble to do a incremental backup,
using some kind of version numbers control.
Uf. Long email. Well, this was just to tell everybody that Backups is
something that we all know that should be improved, there are already some
nice plans to do it, and for now, if you want to make sure that you have a
reliable backup, just restore it on some place else. :-)
Artur
----- Original Message -----
From: "Daniel Rail" <daniel@...>
To: <firebird-support@yahoogroups.com>
Sent: Tuesday, June 24, 2003 10:31 AM
Subject: Re: [firebird-support] confiable backup?
> Hi,
>
> At June 24, 2003, 05:43, Artur Anjos wrote:
> > The way to do a safe backup is:
>
> > - Gbak to create the backup;
> > - GBak to restore it on a different place;
>
> Take the following scenario:
>
> 1- You create a backup of your production database without knowing if
> it is good or not.
> 2- Your production database gets corrupted sometime after, up to the
> point that you can't use it.
> 3- You attempt to restore your backup, but your backup is not good and
> doesn't want to restore.
>
> End result: You have a corrupted database that is unusable and a
> backup that can't be restored. So, what's next, pay IB Phoenix to see
> if the corrupted database is fixable.
>
> I think that a backup must be a sure thing. If there are problems
> with the database when performing a backup, it should be indicated
> at that moment. Not when performing the restore, once it's too late.
> Not everybody will perform a backup, then immediately after do a
> restore to a different place to see if the backup worked.
>
> I know that some level of check is performed by the backup, but I
> think that all checks should be performed by both the backup and
> restore.
>
> --
> Best regards,
> Daniel Rail
> Senior System Engineer
> ACCRA Group Inc. (www.accra.ca)
> ACCRA Med Software Inc. (www.filopto.com)