Hello,
Just wondered, when creating an application which hold databases
what things i should consider of making a backup?
I know i can just copy the DB file to somewhere else but i am talking in more of a smart way to handle this matter.
I tought of making a var in the DB that spots the last time it was updated and then when a user restores the data it tells him that he is restoring an old DB or somthing like that....
any opnions?
Thanks.
Backup thoeries?
-
Killswitch
- Enthusiast
- Posts: 731
- Joined: Wed Apr 21, 2004 7:12 pm
How about this:
The first time a database is edited/created do nothing, but make a note that the database has been opened for the first time. Then, when it's opened again whatever changes are made make a note of the original and store. So, if a user wants to restore the database back to how it was originally you just read through the changes and convert them back to the original.
The first time a database is edited/created do nothing, but make a note that the database has been opened for the first time. Then, when it's opened again whatever changes are made make a note of the original and store. So, if a user wants to restore the database back to how it was originally you just read through the changes and convert them back to the original.
~I see one problem with your reasoning: the fact is thats not a chicken~
I do that with a production database for my customers. It also has auto-backup with a time they specify. Anyway, here is an easy way:
1) Backup to a zip file into a different directory (preferably on a lan), and stamp the file name, i.e. DBBU_20060622_0100.zip;
2) Just stamp the date-time of the last backup in an INI file.
3) In the restore process, always do a pre-restore backup (time-stamped of course) just to be sure you don't stomp on anything and end up in a backup-garbage-restore-garbage loop.
hope this helps.
1) Backup to a zip file into a different directory (preferably on a lan), and stamp the file name, i.e. DBBU_20060622_0100.zip;
2) Just stamp the date-time of the last backup in an INI file.
3) In the restore process, always do a pre-restore backup (time-stamped of course) just to be sure you don't stomp on anything and end up in a backup-garbage-restore-garbage loop.
hope this helps.
can you imagine roll back to 100 queries ?here's another trick which simplifies my life:
On every table, i add 17 standard meta-data columns, but the most important are:
CREATED_BY
CREATED_DATE
CREATED_TIME
LAST_UPDATED_BY
LAST_UPDATED_DATE
LAST_UPDATED_TIME
and always stamp these columns in your DML statements. This way, you can always know when someone created a record and the last time it was updated - this can be used as an internal way to backup only those records that have changed from the last backup.
Personally, I use them to hunt down people that have messed up the database.
On every table, i add 17 standard meta-data columns, but the most important are:
CREATED_BY
CREATED_DATE
CREATED_TIME
LAST_UPDATED_BY
LAST_UPDATED_DATE
LAST_UPDATED_TIME
and always stamp these columns in your DML statements. This way, you can always know when someone created a record and the last time it was updated - this can be used as an internal way to backup only those records that have changed from the last backup.
Personally, I use them to hunt down people that have messed up the database.
