Subject | Major Incident where db rolled back to restore point |
---|---|
Author | Peter Chaisty |
Post date | 2007-06-11T19:29:06Z |
Hi
I ahd a major incident the other day on a fb thats been running for
about a yr+ with no problems.
The issue is that following a gbak backuprestore we lost 24 hrs of
data when we did another backup.
The sequence of operations and details are as follows
Version no (LI-V6.3.2.4731 Firebird 1.5)
Forced writes are on
june 4th
1/ logged in on linux (fedora)
2/ Closed down all connections
3/ ran gbak to a backups sub dir (local gbak)
4/ did a restore of the backup to another sub dir
5/ renamed original db
6/ copied restored db from backup dir to same name as original (still
as root)
7/ restarted apps running the system
24 hrs later, june 5th
8/ closed down connections
9/ started a backup on remote windows pc using gbak / closed it
because it was taking too long
9/ ran a backup on linux (local gbak) to a sub dir
10/ added an index in workbench forgot to name from the workbench
defualt one it so it was deleted.
11/ added another index named correctly
12/ restarted app using database
13/ next morning we found the db had rolled back to the restore point
in step (3)
14/ disaster we had a hole in the db between (12) and 3
The backup from (9) did contain the missing data
Because we had the backup we have the data to start rebuilding the db
(the customer opted to kep it running after the issue) though a lot of
money and customer confidence was lost.
Really I am just trying to work out what I did wrong so that this will
never happen again. I also need to tell my customer how this happened
and at the moment I don't know.
I would appreciate any ideas.
Pete
I ahd a major incident the other day on a fb thats been running for
about a yr+ with no problems.
The issue is that following a gbak backuprestore we lost 24 hrs of
data when we did another backup.
The sequence of operations and details are as follows
Version no (LI-V6.3.2.4731 Firebird 1.5)
Forced writes are on
june 4th
1/ logged in on linux (fedora)
2/ Closed down all connections
3/ ran gbak to a backups sub dir (local gbak)
4/ did a restore of the backup to another sub dir
5/ renamed original db
6/ copied restored db from backup dir to same name as original (still
as root)
7/ restarted apps running the system
24 hrs later, june 5th
8/ closed down connections
9/ started a backup on remote windows pc using gbak / closed it
because it was taking too long
9/ ran a backup on linux (local gbak) to a sub dir
10/ added an index in workbench forgot to name from the workbench
defualt one it so it was deleted.
11/ added another index named correctly
12/ restarted app using database
13/ next morning we found the db had rolled back to the restore point
in step (3)
14/ disaster we had a hole in the db between (12) and 3
The backup from (9) did contain the missing data
Because we had the backup we have the data to start rebuilding the db
(the customer opted to kep it running after the issue) though a lot of
money and customer confidence was lost.
Really I am just trying to work out what I did wrong so that this will
never happen again. I also need to tell my customer how this happened
and at the moment I don't know.
I would appreciate any ideas.
Pete