Subject | RE: [ib-support] Re: How to assure backup is OK |
---|---|
Author | Alan McDonald |
Post date | 2002-08-13T09:19:40Z |
agreed - very good - but restoring is yet another interesting topic
you mention that you need to ensure noone is connected when restoring.
well there's more to it than that
of course, if you stop everyone who is connected, then restore, everyone
will loose what they were doing between the time of your last backup and the
time of your restore. This can be several hours of work if your scheduled
backup was "last night some time"
When I have been forced to restore a database from a backup, I have raced to
stop all activity and disconnect everyone as the first step. I usually stop
the service, rename the database and then start the service. Anyone who has
ignored (not received) the message to not use the application will be rudely
aware of the application not working.
I have restored to an alternative file name. (now I have the original
"corrupt" version and a restored "good" version.
I have then set about examining the existing database (sometimes this is not
possible because of gross corruption). Usually, though, you can at worst,
backup the existing database and restore it using the ignore checksums etc
options. You now have a restored copy of the database which is workable but
may not be complete. Your restored database from last night or previously
backed up copy a la the four versions of backups comes in handy. This is
where my inclusion of a datecreated and lastupdate field(s) (updated by
triggers) on all tables comes in very handy.
I separate all records which have been created and/or updated post the date
of my last backup.
I can then insert/update these records into the restored backup version and
finally I will have restored version of the database which is mighty close
to the version before the "crash" or corruption.
When I bring the database back to live operation, I announce the date/times
of disruption and ask everyone to examine their most recent data to check if
they finally have to redo some of their edits/entries.
That's the best I've been able to do. In my experience, people cannot
tolerate even an hour's worth of lost data. They don't understand why, in
the 21st century, with backup technology, there should be any lost time at
all. They already lose the time it takes me to carry out these operations.
Sometimes it's taken me all night to do it.
hope this helps
Alan
PS - that backup batch file is very good
-----Original Message-----
From: gkrishna63 [mailto:gkrishna@...]
Sent: Tuesday, 13 August 2002 18:41
To: ib-support@yahoogroups.com
Subject: [ib-support] Re: How to assure backup is OK
Warning - i am also fairly new at using Firebird
I will share what I have learnt but it needs to be validated by other
people who have more experience.
(But then the best way to learn is to teach!!)
A full backup of the server is not going to work. Exclude the main
database from the server backup but include a directory where you
automatically backup your database on a regular basis
You can backup a firebird database even when other people are
connected.
This backup will be a snapshot of the database at the time of the
starting of the backup.
(i.e. all transactions committed after the backup starts will not be
part of the backup even though the backup process may take a long
time).
For restore however all users need to be disconnected.
If garbage collection is enabled during backup, backup can take quite
while. you can disable garbage collection but it is better that you
dont disable it.
An occasional restore of your database is a good way to keep the
indexes well balanced and to recover space and generally keep the
database shipshape. (FB is a low maintenance RDBMS so in fact this
seems to be the only thing you need to do to keep your database
healthy except of course split it up into maultiple files if it
becomes too large. !!)
Earlier posts recommended that it is a good practice to restore your
backup to a different location and check that there are no errors if
you want to be sure that the backup has worked successfully.
(From personal experience i can tell you that this vital.
Dont ask me how it happenned but somehow my DDL script got some funny
entries and after that backup from that particular database would
work successfully but restore would fail
if you want to know the exact entry it was.
CREATE GENERATOR RDB$SECURITY ;
As I said I dont know how the heck that line got in there <g> )
How to do a backup or a restore.
There are two ways
one is the command line utility gbak
(Hint: If you want to use gbak to restore from one machine and the
backup file (typically a .gbk file) is on another machine you need to
use the -se paramter.
I am sharing all the information that caused me headaches and long
nights to figure out <g>)
You can set up a batch file to do this and a schduler to run the
batch file automatically.
I am including a batch file that Fred Wilson had shared on this list
and I had hoarded.
The original post also had a batch file which would log off everbody
and do a backup and a restore.
I could send it if you are interested.
This backup script neatly makes sure that the last four backups are
saved.
<start hoarded post>
@Echo Off
rem
**********************************************************************
****************
rem Backup the database with the normal backup utility
rem
**********************************************************************
****** **********
copy %BUDir%\%DBNam%-2.Bak %BUDir%\%DBNam%-3.Bak
copy %BUDir%\%DBNam%-1.Bak %BUDir%\%DBNam%-2.Bak
copy %BUDir%\%DBNam%.Bak %BUDir%\%DBNam%-1.Bak
%UTDir%\gbak -g -b -user %DBUsr% -pas %DBPwd% %DBDir%\%DBNam%
%BUDir%\%DBNam%.Bak
set Backup0True=%ERRORLEVEL%
rem set flag to true if backup unsuccessful.
rem ****Do not have any line between the gbak and the set command.
the errorlevel will be reset.
rem Create log file with time, date, flag state, and a dir of ga.bak
echo. ------------------------------------------------------- >>
%BUDir%\ibbak.log
date /T >> %BUDir%\ibbak.log
time /T >> %BUDir%\ibbak.log
echo. Backup0True=%Backup0True% >> %BUDir%\ibbak.log
dir %BUDir%\%DBNam%.bak >> %BUDir%\ibbak.log
echo. ------------------------------------------------------- >>
%BUDir%\ibbak.log
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
((((((
((((((((((((((((((((((((((((((((
Best regards,
Fred Wilson
SE, Bell & Howell
fred.wilson@...
<mailto:fred.wilson@...>
<end hoarded post>
The second if you are using Delphi as your programming language is
IBX.
That has a TIBBackupService
(Hint : In the Delphi help Search for IBX click there. This will take
you to the actual help file for all the IBX components)
You can write a small program which will automatically backup at
fixed intervals.
HTH
GK
you mention that you need to ensure noone is connected when restoring.
well there's more to it than that
of course, if you stop everyone who is connected, then restore, everyone
will loose what they were doing between the time of your last backup and the
time of your restore. This can be several hours of work if your scheduled
backup was "last night some time"
When I have been forced to restore a database from a backup, I have raced to
stop all activity and disconnect everyone as the first step. I usually stop
the service, rename the database and then start the service. Anyone who has
ignored (not received) the message to not use the application will be rudely
aware of the application not working.
I have restored to an alternative file name. (now I have the original
"corrupt" version and a restored "good" version.
I have then set about examining the existing database (sometimes this is not
possible because of gross corruption). Usually, though, you can at worst,
backup the existing database and restore it using the ignore checksums etc
options. You now have a restored copy of the database which is workable but
may not be complete. Your restored database from last night or previously
backed up copy a la the four versions of backups comes in handy. This is
where my inclusion of a datecreated and lastupdate field(s) (updated by
triggers) on all tables comes in very handy.
I separate all records which have been created and/or updated post the date
of my last backup.
I can then insert/update these records into the restored backup version and
finally I will have restored version of the database which is mighty close
to the version before the "crash" or corruption.
When I bring the database back to live operation, I announce the date/times
of disruption and ask everyone to examine their most recent data to check if
they finally have to redo some of their edits/entries.
That's the best I've been able to do. In my experience, people cannot
tolerate even an hour's worth of lost data. They don't understand why, in
the 21st century, with backup technology, there should be any lost time at
all. They already lose the time it takes me to carry out these operations.
Sometimes it's taken me all night to do it.
hope this helps
Alan
PS - that backup batch file is very good
-----Original Message-----
From: gkrishna63 [mailto:gkrishna@...]
Sent: Tuesday, 13 August 2002 18:41
To: ib-support@yahoogroups.com
Subject: [ib-support] Re: How to assure backup is OK
Warning - i am also fairly new at using Firebird
I will share what I have learnt but it needs to be validated by other
people who have more experience.
(But then the best way to learn is to teach!!)
A full backup of the server is not going to work. Exclude the main
database from the server backup but include a directory where you
automatically backup your database on a regular basis
You can backup a firebird database even when other people are
connected.
This backup will be a snapshot of the database at the time of the
starting of the backup.
(i.e. all transactions committed after the backup starts will not be
part of the backup even though the backup process may take a long
time).
For restore however all users need to be disconnected.
If garbage collection is enabled during backup, backup can take quite
while. you can disable garbage collection but it is better that you
dont disable it.
An occasional restore of your database is a good way to keep the
indexes well balanced and to recover space and generally keep the
database shipshape. (FB is a low maintenance RDBMS so in fact this
seems to be the only thing you need to do to keep your database
healthy except of course split it up into maultiple files if it
becomes too large. !!)
Earlier posts recommended that it is a good practice to restore your
backup to a different location and check that there are no errors if
you want to be sure that the backup has worked successfully.
(From personal experience i can tell you that this vital.
Dont ask me how it happenned but somehow my DDL script got some funny
entries and after that backup from that particular database would
work successfully but restore would fail
if you want to know the exact entry it was.
CREATE GENERATOR RDB$SECURITY ;
As I said I dont know how the heck that line got in there <g> )
How to do a backup or a restore.
There are two ways
one is the command line utility gbak
(Hint: If you want to use gbak to restore from one machine and the
backup file (typically a .gbk file) is on another machine you need to
use the -se paramter.
I am sharing all the information that caused me headaches and long
nights to figure out <g>)
You can set up a batch file to do this and a schduler to run the
batch file automatically.
I am including a batch file that Fred Wilson had shared on this list
and I had hoarded.
The original post also had a batch file which would log off everbody
and do a backup and a restore.
I could send it if you are interested.
This backup script neatly makes sure that the last four backups are
saved.
<start hoarded post>
@Echo Off
rem
**********************************************************************
****************
rem Backup the database with the normal backup utility
rem
**********************************************************************
****** **********
copy %BUDir%\%DBNam%-2.Bak %BUDir%\%DBNam%-3.Bak
copy %BUDir%\%DBNam%-1.Bak %BUDir%\%DBNam%-2.Bak
copy %BUDir%\%DBNam%.Bak %BUDir%\%DBNam%-1.Bak
%UTDir%\gbak -g -b -user %DBUsr% -pas %DBPwd% %DBDir%\%DBNam%
%BUDir%\%DBNam%.Bak
set Backup0True=%ERRORLEVEL%
rem set flag to true if backup unsuccessful.
rem ****Do not have any line between the gbak and the set command.
the errorlevel will be reset.
rem Create log file with time, date, flag state, and a dir of ga.bak
echo. ------------------------------------------------------- >>
%BUDir%\ibbak.log
date /T >> %BUDir%\ibbak.log
time /T >> %BUDir%\ibbak.log
echo. Backup0True=%Backup0True% >> %BUDir%\ibbak.log
dir %BUDir%\%DBNam%.bak >> %BUDir%\ibbak.log
echo. ------------------------------------------------------- >>
%BUDir%\ibbak.log
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
((((((
((((((((((((((((((((((((((((((((
Best regards,
Fred Wilson
SE, Bell & Howell
fred.wilson@...
<mailto:fred.wilson@...>
<end hoarded post>
The second if you are using Delphi as your programming language is
IBX.
That has a TIBBackupService
(Hint : In the Delphi help Search for IBX click there. This will take
you to the actual help file for all the IBX components)
You can write a small program which will automatically backup at
fixed intervals.
HTH
GK
--- In ib-support@y..., "mivi71dk" <Michael.Vilhelmsen@M...> wrote:
> This sound like a good idea.
>
> But the problem is, that our program is sold to many people with
> little or no IT experience.
>
> Therefore they don't know what to look for, how to do things etc.
> So to make things as simpel as posible (as far as the user is
> concerned) we set up the backup software to do a FULL backup of
they
> server(s).
>
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[Non-text portions of this message have been removed]