How to Back Up and Restore a QAD Progress Database with probkup and prorest
How to back up a QAD Progress database online with probkup
Also searched as
- QAD database backup procedure probkup
- prorest restore QAD database
- Progress incremental backup probkup
- QAD backup and recovery best practice
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.
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.
Back up and restore procedure
- 1Confirm the database is started with a broker (proserve) so an online backup is possible, and that free space exists on the backup target.
- 2Run a full online backup: probkup online dbname full-backup-file. Online backup does not require users to log off.
- 3Between fulls, run incremental backups with probkup online dbname inc-file incremental, and keep the full backup they depend on.
- 4Verify each backup with prorest dbname backup-file -vp. This reads the media and checks it without restoring.
- 5Copy backups to separate storage, away from the database server, and record backup dates, database version, and structure file.
- 6To restore, recreate the structure with prostrct create from the .st file, then run prorest dbname full-backup-file, followed by each incremental in order.
- 7If after-imaging is enabled, apply after-image files with rfutil roll forward to reach the desired point in time.
- 8Start the restored database on a test server first, open QAD, and run sanity checks before pointing users at it.
Why online probkup rather than a file copy
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.
# 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
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
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.
# 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
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.
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Can users stay logged in during probkup online?
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?
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?
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?
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.
Related
QAD "Lock Table Overflow, Increase -L on Server (915)": Cause and Fix
Progress error 915 means the database server ran out of entries in its shared record lock table, which is sized by the -L startup parameter. Either one session holds an enormous number of record locks inside a single transaction, or -L is simply too small for your workload. Find the session first, then raise -L in the database startup parameters and restart the database.
Error fixQAD Progress BI File Growing Huge: Causes and How to Truncate It
The before-image (.bi) file grows when Progress cannot reuse its clusters, usually because a long-running transaction is still open or the cluster size is too small. Find the oldest open transaction, end it, then if the file is still oversized do a clean shutdown and run proutil truncate bi with a sensible cluster size. Never delete the .bi file by hand.
Error fixQAD Says "Unable to Connect to the Application Server": How to Fix It
This error almost always means the Progress OpenEdge AppServer broker behind QAD is stopped, unreachable over the network, or out of licensed connections, not a database problem. Confirm the broker process is running and healthy in OpenEdge Explorer, check the port and firewall path from the client, then restart the broker with clean agent settings.
How-toHow to Create a Generic Inquiry in Acumatica
Generic Inquiries (GI) are Acumatica's no-code query builder for joining tables, adding filters, and exposing the result as an inquiry screen, dashboard data source, or API endpoint. Open System > Customization > Generic Inquiry, add your base table, define joins and conditions, then run and save. No SQL or customization project is required.
Error fixFix Odoo AccessError: You Are Not Allowed to Access Records
Odoo raises AccessError when a user's security groups do not grant a CRUD right on a model through ir.model.access.csv, or when an ir.rule record rule filters the specific record out for that user or company. Fix it by adding the user to the group named in the error, editing the model's access rights, or reviewing the record rule's domain under Settings > Technical > Security.
How-toHow to Void a Check in Sage 100
Sage 100 voids checks through Accounts Payable > Main > Check and Payment Voiding. Select the bank code, choose the check number, and Sage reverses the Cash Disbursements Journal entry and reopens the invoice it paid. A check that already cleared in Bank Reconciliation or falls in a closed period needs an extra step before it can be voided cleanly.
AI for ERPAI for QAD Adaptive ERP in automotive and industrial manufacturing
Add AI to QAD Adaptive ERP or Enterprise Edition for automotive and industrial manufacturing, grounded on QXtend and QAD's API layer, on-prem or private cloud.
AI for ERPAI for QAD in Medical Devices: Traceability, DHR Review and CAPA Trends Without Exposing Regulated Data
Private, read-only AI on QAD for medical device makers: DHR review, UDI and lot traceability, CAPA and complaint trends under FDA QMSR and ISO 13485.
Stuck on QAD Enterprise Applications (Progress OpenEdge database)?
Talk to engineers who work inside QAD Enterprise Applications (Progress OpenEdge database) every week, and who build private AI that answers these questions from your own ERP data.