What is Point-in-time recovery?

Where Point-in-time recovery goes wrong in real apps

Each of these is a short scenario built from a real failure in an app made with AI. Read the answer here, or walk through it yourself in about four minutes.

• Data you can lose · 4 minutes · Pro

  The backup that wasn't there

  At 4pm a bad script deletes your orders table. You open the backups page expecting to undo it.

  How much data can daily backups lose?

  Up to a full day. A daily backup restores the database as it was when the backup ran, so everything written since is lost. Point-in-time recovery can restore to any minute by replaying the database log. Whatever you use, test a restore before you need it.

  Read the fix

• Data you can lose · 5 minutes · Free

  The agent that reset production

  You asked your coding agent to fix a failing migration. It says it 'reset the database to resolve drift'. Your live customers are gone.

  How do I stop an AI agent deleting my database?

  Do not keep production database credentials where the agent runs. Use a separate development database locally, give production a role that cannot drop tables, and keep backups the agent cannot reach. Instructions like 'never touch production' are not enough; only permissions reliably stop a destructive command.

  Walk it, free

Related terms

Database

Where your app keeps its data, organised in tables, like a set of spreadsheets.

Table, row, column

A table is like one spreadsheet (orders). Each row is one item (one order); each column is one detail (price, date).

Backup

A saved copy of your data from a moment in time, so you can get it back after a mistake.

Secret key

A password your app uses to talk to a paid service. Anyone who sees it can use it, and spend your money.

Environment variable

A setting stored outside your code, like a secret key. Your laptop and your live site each have their own copy.

Production

The real, live version of your app that customers use, as opposed to the copy on your laptop.