# How to Back Up and Restore a QAD Progress Database with probkup and prorest > Source: https://netray.co/erp-help/qad-progress-database-online-backup-probkup-restore-prorest > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Use probkup online to take a consistent full backup of a running QAD database, add incremental backups between fulls, verify the backup with prorest -vp, and restore with prorest into a prepared structure. A file-level copy of a running database is not a valid backup. Pair backups with after-imaging if you need point-in-time recovery. ## Kind how-to ## System small-erp ## Erp QAD Enterprise Applications (Progress OpenEdge database) ## Module System Administration - Database Backup and Recovery ## Query How to back up a QAD Progress database online with probkup ## Alternate Queries - QAD database backup procedure probkup - prorest restore QAD database - Progress incremental backup probkup - QAD backup and recovery best practice ## Applies To QAD Enterprise Applications databases on Progress OpenEdge 10.2B through 12.x. Commands are the same on Linux, UNIX and Windows apart from path syntax. ## Steps ### Back up and restore procedure **Items:** - Confirm the database is started with a broker (proserve) so an online backup is possible, and that free space exists on the backup target. - Run a full online backup: probkup online dbname full-backup-file. Online backup does not require users to log off. - Between fulls, run incremental backups with probkup online dbname inc-file incremental, and keep the full backup they depend on. - Verify each backup with prorest dbname backup-file -vp. This reads the media and checks it without restoring. - Copy backups to separate storage, away from the database server, and record backup dates, database version, and structure file. - To restore, recreate the structure with prostrct create from the .st file, then run prorest dbname full-backup-file, followed by each incremental in order. - If after-imaging is enabled, apply after-image files with rfutil roll forward to reach the desired point in time. - Start the restored database on a test server first, open QAD, and run sanity checks before pointing users at it. ## Sections ### Why online probkup rather than a file copy **Body:** A Progress database is a set of extents (.d1, .d2, the .bi before-image file, and others) that are only consistent as a whole. Copying them while the database is running produces extents from different moments, and the restored copy may be corrupt or unable to recover. probkup online takes a consistent snapshot while users keep working. It coordinates with the database so the backup represents a single point in time, which is why it is the standard method for 24x7 QAD sites such as plants running multiple shifts. An offline backup (shut the database down, then run probkup without online) is also valid and simple, but it requires downtime. Many sites use an online full weekly and incrementals nightly, plus periodic offline backups before upgrades. **Code:** # Full online backup probkup online /qad/db/mfgpro /backup/mfgpro_full_$(date +%Y%m%d).bak # Incremental online backup probkup online /qad/db/mfgpro /backup/mfgpro_inc_$(date +%Y%m%d).bak incremental # Verify without restoring prorest /qad/db/mfgpro /backup/mfgpro_full_20260101.bak -vp ### Incremental backups and what they depend on **Body:** An incremental backup captures only blocks changed since the last backup, which makes it much smaller and faster. But it is useless without the chain it belongs to: to restore, you apply the last full backup first, then each incremental in sequence. Keep the full and the incrementals together and number them clearly. A common failure is a retention job that deletes the old full backup while newer incrementals remain, leaving a chain that cannot be restored. Run a full backup at least weekly. A long chain of incrementals slows restore, and every extra link is one more file that must be intact when you need it. ### Restoring into a prepared structure **Body:** A restore needs somewhere to put the data. If the original server is lost, recreate the directory layout, copy the structure (.st) file, and run prostrct create to build empty extents. If you restore over an existing database, prorest will warn you before overwriting. prorest checks that the target structure can hold the data. If extents are too small, the restore stops and tells you. You can add extents with prostrct add and retry. After restore, if you use after-imaging, the restored database is at the time of the backup. Roll forward with the archived after-image files using rfutil to reach the moment just before the failure. **Code:** - # Recreate structure, then restore prostrct create /qad/db/mfgpro /qad/db/mfgpro.st prorest /qad/db/mfgpro /backup/mfgpro_full_20260101.bak prorest /qad/db/mfgpro /backup/mfgpro_inc_20260102.bak - # Roll forward after-image files (if enabled) rfutil /qad/db/mfgpro -C roll forward -a /backup/ai/mfgpro.ai1 ### Testing recovery, not just taking backups **Body:** A backup you have never restored is a hope, not a control. Schedule a restore test to a scratch server at least quarterly, and after every major change such as a QAD upgrade or database dump-and-load. Time the restore. If a full restore plus incrementals takes six hours and your plant can tolerate two, you have found a gap while it is cheap to close, for example by adding a warm standby with OpenEdge Replication. Also record which QAD application version matches the database. Restoring a database without the right application code and configuration leaves you with data you cannot use. ## Pitfalls - Copying database files with the OS while the database is running and calling it a backup. - Deleting the base full backup while keeping incrementals that depend on it. - Never running prorest -vp, so a corrupt backup is discovered only during an emergency. - Storing backups on the same disk or server as the database. - Forgetting to back up the .st file, application code, and configuration needed to rebuild the environment. - Enabling after-imaging without archiving the after-image files, which eventually fills the disk. ## Ai Angle An assistant grounded in your QAD environment can generate the backup schedule and scripts for your paths and retention policy, read backup logs to flag a missed incremental, and draft a restore runbook from your structure file. It works best as a reviewer of logs and procedures. Actual backups and restores should run from your scheduler and be executed by your DBA, not by an AI agent. ## Faq ### Can users stay logged in during probkup online? **Answer:** Yes. An online backup is designed to run while the database is up and users are working. There may be a modest performance impact while it runs, so schedule it outside peak production hours. Offline backups require shutting the database down first. ### How often should I run full and incremental backups? **Answer:** A common pattern is a full backup weekly and an incremental nightly. Busy sites with strict recovery targets add after-imaging for point-in-time recovery. The right frequency depends on how much data loss and downtime the business can accept, so agree those targets first. ### What does prorest -vp do? **Answer:** The -vp option verifies the backup media: it reads the backup and checks its integrity without restoring any data. It is a quick way to catch unreadable or truncated backup files, though only a real test restore proves the whole recovery process works. ### Do I need after-imaging for QAD? **Answer:** Only if losing up to a day of transactions is unacceptable. After-imaging records changes continuously so you can roll forward from a backup to a precise time. It adds administrative work, since after-image files must be switched, archived and monitored. ## Search terms QAD database backup, probkup online, prorest restore, Progress incremental backup, OpenEdge backup best practice, rfutil roll forward, QAD disaster recovery, prostrct create, Progress after imaging, QAD DBA tasks --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json