Websites
Point-in-Time Recovery
Point-in-time recovery lets you rebuild your database as it was at a chosen minute, rather than only at the moment yesterday's backup ran. This guide covers what it does and does not cover, how to enable it, how to request a restore, and exactly what a restore touches.
What It Is For
A daily backup gives you one restore point per day. That is fine for most disasters and useless for the specific one where a bad import, a broken plugin, or a mistaken bulk edit ran at 2:15pm and you noticed at 4pm. Restoring yesterday's backup would throw away the entire morning's real work along with the mistake.
Point-in-time recovery closes that gap. With it enabled, the database's change log is shipped continuously to offsite storage, so a restore can be replayed up to any minute inside the retained window.
Point-in-time recovery covers the DATABASE only. It does not cover your files: no uploads, no theme or plugin code, no configuration files on disk. If someone deleted a folder of images, PITR will not bring it back. For files you need a file backup. See Taking a Backup and Restoring From a Backup.
Where It Lives in KPanel
- Sign in to KPanel.
- Click Websites in the left sidebar, then click the site.
- In the site's tab strip, open Backups, then Point-in-time recovery.
The direct address is /websites/<site-id>/pitr.
Eligibility
Point-in-time recovery needs two things to be true.
Your plan must include it. It is available on the WordPress plan families.
The site must be a WordPress or WooCommerce site, because the mechanism relies on a managed database.
If either is not met, the page says so plainly: point-in-time recovery is only available for WordPress and WooCommerce sites with managed databases. There is nothing to configure in that case.
Enabling It
The PITR status card shows the current state with a status pill, the backend in use, when the last change log was shipped, and the retention window in days.
Click Enable PITR to switch it on. Retention is 30 days.
Enabling changes nothing about your data. It starts a continuous shipping process that runs alongside your normal daily backups; it does not replace them.
There are no restore points immediately after enabling. Shipping has to run at least once before anything can be replayed, and the first shipment happens within about five minutes. Until then the page tells you there are no restore points yet.
Reading the Restore Window
Once shipping is running, the Available restore window card states the earliest and latest moments you can restore to, and how many change log files are being retained to cover it.
Read this before you need it, not during an incident. If the window starts later than you expected, shipping was interrupted at some point and older coverage has expired.
Requesting a Restore
- Open the Point-in-time recovery tab.
- Confirm the restore window covers the moment you want.
- In Restore to timestamp, pick the date and time. Choose a moment just BEFORE the damage, not after it.
- Click Request restore to staging DB.
The request is validated straight away. If the timestamp falls outside the available window, you are told the exact window rather than being left to guess.
What a Restore Actually Does
This is the part to be precise about, because it is the opposite of what most people expect.
A point-in-time restore does not touch your live database. It restores into a separate staging database, which is created for the purpose and named after your domain and the target date. Your live site keeps running on its own database throughout, unchanged.
Nothing is overwritten, nothing is deleted, and no data is lost by requesting a restore. That is deliberate: the whole point of a data-recovery tool is that using it cannot make the situation worse.
What you get is a database you can inspect. You can compare it with the live one, pull out the rows that were damaged, or decide the whole snapshot is the version you want. Promoting a staging restore over your live database is a separate, deliberate step our team does with you, not something a button does behind your back.
Cutting over to a restored database DOES discard everything written to the live database since the restore point. Orders placed, comments left, and content edited after that timestamp exist only in the live database. Before any cutover, decide what has to be carried forward and say so. This is why the restore lands in staging first.
Tracking the Request
Every request appears in the Restore requests table:
| Column | What it shows |
|---|---|
| Requested | When you asked for it |
| Target | The timestamp you asked to restore to |
| Status | Where the request has got to |
| Staging DB | The name of the database being restored into |
While a restore is running, the status shows the current stage and, once replay begins, how many change log files have been applied out of the total. A failed request shows the error underneath.
Only one restore can be in flight per site at a time. Requesting a second while one is running returns a conflict rather than queueing, so a second attempt cannot corrupt the first.
Our engineering team completes the staging restore and emails you when the staging database is ready. You also get a confirmation email when the request is received, with the target timestamp and the staging database name.
Choosing the Right Timestamp
Work out when the damage started, not when you noticed. These are usually hours apart. Check your activity log, your order timestamps, or your last known-good content edit.
Aim a minute or two earlier. A restore point just before the bad event costs you a couple of minutes of legitimate writes. One just after it restores the damage along with everything else.
Write down what happened after the restore point. Orders, sign-ups, comments, form submissions. That list is what you will need to carry forward manually if you cut over.
Troubleshooting
The page says PITR is only available for WordPress and WooCommerce. Either the site is not one of those types, or your plan does not include the feature.
No restore points yet. Shipping needs to run at least once after enabling. The first shipment happens within about five minutes.
My target is outside the available window. Retention is 30 days, and the window can be shorter if shipping was interrupted. The error message states the exact bounds. If the moment you need has aged out, fall back to a daily backup: see Restoring From a Backup.
A restore is already in progress. Wait for it to finish. The table shows its stage and progress.
The status shows a banner about the shipper. Your request is recorded and the message explains the current state. Nothing is lost.
I need the files back, not the database. PITR cannot help. Use a file backup, and note that a completed backup can be browsed file by file rather than restored whole.
Related Pages
- Taking a Backup for the daily file and database backups that run alongside this.
- Restoring From a Backup for the whole-site restore path.
- Staging Environments for testing changes before they reach production.
- Site Security if the data loss was caused by a compromise rather than a mistake.
If you are in the middle of an incident and unsure which tool you need, contact us from Support in KPanel or email support@kapsulehost.com with the site name and the time the problem started.