From the outset:
3rd Party backup/replication utilities are not supported by Progress, they are supported by the Vendor. We do not support issues related to restoration of databases using backup files that were not generated by PROBKUP or taken online without a PROQUIET raised and entire database files included. Neither do we support integrity issues that may arise from 3rd Party Replication technologies. The only supported replication solutions are OpenEdge Replication and PRO2.
There are many 3rd party softwares on the market (used worldwide). If the end user has a requirement to run these on their environment, then Application Partners work together with their end users and that 3rd party organisation in resolving any issues that may arise. We do not supply, certify or have any knowledge of these utilities, that is what their support services specialize in, as we similarly specialize in our products.
Unless the problem can be reproduced without the 3rd party influence, then it's not a Progress technical issue, it is an issue with the 3rd party product which the end user and application partner whom has a vested interest in their application runtime environment, need to resolve together with the 3rd Party vendor.
In a nutshell:
use the correct tools for the correct job. For Progress that means using:
- PROBKUP online or offline. An online PROBKUP, ensures that memory resident updates (database buffer pool and the BI buffers) are first flushed to disk before the online PROBKUPis initiated. For further details refer to Article What happens during an online backup of the database?
- PROQUIET for any OS / mirroring / snapshot copies to quiesce the database after first synchronizing database buffers to disk.
- OpenEdge Replication for replicated sites. OpenEdge Replication uses on continual transaction roll forward, recording it’s own bi notes. When the target (backup) is needed to restore the production database, it relies on bi recovery in line with OpenEdge database design
Review the section "
Performing an operating system backup" in the
OpenEdge Database Administration manual for further details on backing up and restoring a Progress database using non-Progress backup methods and the
OpenEdge Replication User Guide.
Considerations with 3rd Party offerings: (this list is by no means conclusive)
- While crash recovery succeeds in most instances, the data physically on disk is not anything like the data in a running database (assuming production and reasonable workload). The data you're expecting to see after the restore may not be what is expected and there may very well be be logical data integrity issues that are only discovered too late post restore. These are rarely tested in POC environments when the 3rd Party utility is under consideration.
- Anything that's replicating writes on disk is not going to provide a reliable recovery as essentially it is a 'crashed' database that is being recovered with no account of the data in shared-memory when the database was running. In a true Disaster Recovery scenario, data can be easily be lost as a result of the System Down situation, thus causing database integrity and even accessibility issues afterwards. For example: when the source system dies, it's most likely that the physical database files are out of sync with the BI files, which means that BI rollback recovery may not even be possible on the target database.
- Anything that's backing up "incremental changes to files" or mirroring block updates is not going to be reliable. For databases, the 'files' (ai bi data) are all different and can use different blocksizes that are different to the file system block size and how the 3rd Party decides what qualifies as a 'change'. For databases we're most interested in database blocks, specifically their content. In order to guarantee recovery, a Progress database needs to have the Write Ahead Logging (WAL) protocol observed. The Progress Before Image (bi) and After Image (ai) files must be written before the database files. The only way to maintain and ensure the integrity of Progress data would be to update the blocks in the same order that Progress updates them and 3rd Party solutions cannot differentiate between database 'files'.
- If the database is ever accessed in single user mode, then forget it. Do not attempt to use a non-Progress backup to copy the files on disk as they are dynamically being updated and the non-Progress tool will most likely catch the files midstream and the resultant files will more than likely be out of sync.
- Virtualization layer backups are unreliable for stateful workloads. They cannot safely backup a running database if there are no tools to talk to the database and quiesce the database and filesystem beforehand. Moreover, snapshot mechanisms are not application aware which can cause a multitude of issues in production environments.
