Transaction Backup

From CometWiki

Revision as of 02:26, 27 August 2009

Transaction Backup/Checkpoint/Rollback

Transaction Backup is both simple and complex.

Backup

The server will record every packet that comes to it that modifies data. There is a finite number of these packets that the file server receives:

• Create a file
• Erase a file
• Delete a record
• Write a record. (includes all variants such as write, rewrite, update, insert, etc.)

These "transactions" will be written to a file. Each transaction will have a serial number which just increments each time a transaction is written. The transaction file will be "cycled" every so often. That is, a new transaction file will be created with its name containing the next transaction number. Cycling will be triggered by some time increment or some number of transactions. This will produce potentially many transaction files, but will allow them to be transmitted from server to server relatively easily.

• To be decided:

What is the file type? Where does it live? What does it contain?

Checkpoint

Periodically, the server will perform a "checkpoint". That is it will make a copy of all data which is valid up a certain point in time to a backup folder.

When a checkpoint is initiated, the server will perform the following steps:

• Remember the next transaction number (lets call it 1111111)
• Start copying files from the main directories to a backup folder.
• When copying is finished, remember the last transaction number. (lets call it 2222)
• "Play" the transactions to the files in the backup folder from the first one to the last one (1111 to 2222)
• Compress all of the backup folder and form the name of the the compressed file with the time of the last transaction played back and the last transaction number it contains (in our example, 2222).

Rollback

At any time, the user can "rollback" the whole system by restoring a checkpoint and playing transactions up to a desired point in time. This could be on a completely different system than the main server. This would facilitate migration to a new server, making a test system, or whatever.

Added Benefits

There are several added benefits from this feature

• The Disaster Recovery Service could work with transaction files, potentially speeding up the whole process. Transaction files could be transmitted many times a day making the whole service more valuable.
• Developers could analyze transaction files to determine just how some record was modified etc.