Backup Repstance Files

Regular backups are essential to ensure that data is not lost and that the system can be restored in the event of a failure. For Repstance, it is important to back up several key types of files regularly:

Trail Files: These files are crucial for maintaining the transaction logs. They are located in the 

/opt/repstance/trail

 directory. Regularly backup these files to avoid losing any transactional data. Here is an example command to back up trail files:

Configuration Files: Configuration files contain all the settings and preferences for Repstance. They are found in the 

/opt/repstance/conf

 directory. Ensuring these files are backed up will help in quickly restoring the system configurations. Here is an example command to back up configuration files:

Capture Checkpoint Files: These files keep track of the last transaction processed by a Capture Process, there is one file for each Capture Process (captureckpt.1, captureckpt.2, …). They are located in the 

/opt/repstance

 directory. Backing up these files is essential to resume processing from the correct point after a recovery. Here is an example command to back up capture checkpoint files:

Recording the State of the Processes: The position of an Apply Process is not stored in these files. It is stored in the Target database, so it is backed up and restored together with that database (for the S3 target it is stored in the /opt/repstance/trail/s3 directory). To ensure accurate recovery, it is also important to record the last captured and applied changes at the time of the backup. The “status” command shows them (see Status of any Capture or Apply Processes). You can store this information in a file of your choosing, making it easier to reference during restoration. Here is an example command to record the state of the Processes:

Automated Backup Script

For convenience, you can create a script to automate the backup process:

Important Considerations

Consistent Copy: The trail and checkpoint files are updated while the Capture Processes are running, so a copy made at that time may not be consistent. Stop the Capture Processes before copying the files (see Stop any Capture or Apply Processes) and run them again when the copy is complete, or copy a snapshot of the /opt/repstance directory.

Schedule Regular Backups: Automate the backup process by scheduling the script to run at regular intervals using cron jobs.

Verify Backups: Periodically verify the integrity of the backup files to ensure they are complete and can be used for restoration.

Secure Storage: Store backup files in a secure location to prevent unauthorized access and ensure data privacy.

Restore Repstance Files

To restore the files from a backup, stop the services first (see How to Stop Repstance Services):

If the trail directory, the configuration directory or the checkpoint files exist, move them aside, so that old and restored files are not mixed. Then copy the files of the backup back and give them to the user that runs the services:

Use the trail files and the checkpoint files of the same backup: a checkpoint file holds the number of the trail file that the Capture Process writes as well as its position in the Source database. Start the services (see How to Start Repstance Services) and compare the output of repcli status with the status.txt that was recorded at the time of the backup:

Source database: The Capture Process continues from the position of the restored checkpoint, so the Source database must still have the changes from that position: the archived redo logs of an Oracle database, the change data of SQL Server CDC.

Target database: If the Target database is restored as well, restore it from the same moment as the Repstance files: the position of an Apply Process is stored in the Target database.

Lost checkpoint file: A Capture Process of a SQL Server Source Database rebuilds a missing or damaged checkpoint file from the trail files when it starts. A Capture Process of an Oracle Source Database starts like a new one, at the current SCN of the Source Database, so the changes made in the meantime are not captured: restore the file from the backup, or reset the process to the position that you need (see Reset Process) and repair the data (see DATA COMPARISON).