A nightly cleanup job removes abandoned drafts from your order app's Postgres database. Suppose the job starts deleting active orders on Tuesday, and a customer reports them missing the following Monday. To recover those orders, your team needs a copy from before the cleanup, because Sunday's backup already reflects the deletion.
Backup retention sets how far back your saved copies reach. Choose a window that gives your team time to notice a mistake, investigate it, and start a restore before the last clean copy expires. Then test a restore near the oldest point you expect to reach. How often you save data and how long the app can be down are separate decisions.
Start with an error someone could miss
At Parcel, the order app in this example, the team checks failed requests each day, so a broken checkout route would likely draw attention quickly. A cleanup job that removes a few active orders is harder to catch if customers only return to those orders a week later.
Before choosing a retention period, the team lists a few ways data could go wrong and asks who would notice each one and when. The daily dashboard helps when a failure shows up in the metrics it tracks. A change to an old order, for example, may go unnoticed if it causes no new request errors.
| Possible mistake | Time to notice | Time to investigate | Window to plan around |
|---|---|---|---|
| Checkout writes fail after a release | One hour | Two hours | Same day |
| A nightly job changes order totals | Four days | One day | More than five days |
| Cleanup removes an active draft | Ten days | Two days | More than twelve days |
These are estimates for Parcel. Your app may need very different numbers. Allow time for weekends, a missing reviewer, and the work needed to request a restore. If a copy expires while you investigate, it will not help that incident.
For Parcel, seven days would leave the last case uncovered. The team could keep older copies, detect missing drafts sooner, or ask the business owner to accept the gap. Writing down that choice makes the risk clear.
Separate the age of a backup from the gap between backups
If Parcel saves one backup each night and keeps it for thirty days, the team has many old states to choose from. A failure just before tonight's backup could still leave most of today's changes outside the latest copy.
The largest acceptable data loss is often called the recovery point objective, or RPO. Parcel might write its goal as “We need to recover all but an hour of new orders.” To meet that goal, it needs a way to recover changes made between daily backups, however long it keeps those copies.
Postgres can support point-in-time recovery. It starts with a base backup and applies archived write-ahead logs, which record changes to the database. The required backup and logs must all be available for the chosen time. Check that log archiving works as well as checking that backups finish. PostgreSQL recovery guide
The longest acceptable outage is the recovery time objective, or RTO. Count the time to choose a copy, restore it, check the data, and reconnect the app. The database can restore successfully and still take too long to get customers back into the app.
Plan for orders saved after the mistake
Parcel's customers keep placing valid orders after Tuesday's cleanup. If the team points the app at a Monday restore, customers can see the deleted drafts again, but the valid orders placed since the restore point will be missing.
Before making that switch, the team needs to preserve valid changes made after the error. It might recover selected records from an isolated restored copy, or rebuild safe changes from another trusted record. The right method depends on the schema and on which systems have already acted on the data.
For example, a payment may already have been collected for a later order. Replaying that order must not collect the payment again. Assign someone to review these effects before you reconnect the live app.
Include the work of identifying and preserving later changes in the recovery plan and downtime estimate. The older the copy you choose, the more changes the team may have to review.
Test the oldest useful copy
Run a drill in a separate environment with synthetic records, using a restore date close to the oldest date your policy promises. A restore near the edge of a two-week window checks that the team can still retrieve and use copies that old.
Save a few known order IDs and their expected values before the drill. Check that the restored database contains the records expected at that time. Then connect a test copy of the app, read an order, and save a harmless change. Keep emails, payments, and scheduled jobs disabled so the drill cannot contact customers.
Measure from the start of the drill until the app becomes usable, including any time spent waiting for support or finding the right credentials. If a step fails, fix the cause and repeat that step before relying on the policy.
Give retained data a clear owner
A backup can still hold personal data that has since been removed from the app. Record who may restore it, where a restored copy may run, and when each copy should expire. Have the person who owns legal and contract duties review those choices.
Include manual exports and snapshots in that record, because a retention setting that expires automated copies may leave an export in storage. Give the owner enough information to find each copy and explain why the team keeps it.
Review the policy when Parcel adds a new job, changes its data rules, or signs a contract with stricter recovery needs. A window chosen for an early prototype may stop fitting as the product grows.
Check the actual restore window on Forte
Forte's shared Postgres tier is open beta. It gets daily backups kept for seven days, and restores go through support. Dedicated Postgres is in closed alpha and requires access. It adds point-in-time restore with retention from one to 35 days, seven by default. Forte database guide
For dedicated databases, the documented window starts 12 hours inside the retention period and ends at the latest archived change. Seven days of retention therefore reaches back 6.5 days. A new database may have a shorter window because it starts at its first backup. Read the dates in the Backups tab before selecting a target. Forte restore details
A dedicated restore creates another database. Services remain connected to the source until you move them. Check the restored data and plan how to preserve later writes before making that change. Dedicated databases run on a single node, and beta features have no GA commitments unless agreed in writing. Forte database tiers
Parcel's longest example requires a window of more than twelve days. Use the database guide to compare that need with the tier's actual restore window, then choose an owner and a date to test it.