Backup and recovery

Netlify automatically backs up your database based on two triggers. How long your backups are retained differs by plan.

All backups include the full data and schema (i.e., structure of the database), and can be used to restore your database to exactly how it was when the backup was taken.

Backups are always taken off the production branch of the database. When restoring a backup, it is always the production branch that gets replaced with the backup contents.

When are backups taken

On a schedule: A backup is taken every day at midnight (UTC). This does not depend on the level of activity in your database or project, and requires no action on your part.

On publish: When a production deploy is published for a project that has a database, a backup is automatically taken.

For example, if you add a new field to your online store inventory in an agent run or pull request and then publish these changes to production, then Netlify will automatically back up your database once your production deploy goes live.

Netlify takes this backup because issues affecting database data are typically correlated with a new deploy containing faulty code or schema changes (even if the schema remains the same, a bug in a new code version can alter data in unwanted ways). For safety, this type of backup is taken on any new published deploy, regardless of what has changed in that deploy and whether its code has any new database migrations.

Backups and manual publishing

By default, any new production deploy in a Netlify Project is automatically published. That means that a backup is taken for any new successful production deploy, just prior to its automatic publishing.

However, there are two cases in which deploys are manually published by a user, and require more attention regarding backup & restore:

• When rolling back to a previous deploy.
• When auto-publishing is locked and a user manually chooses when to publish deploys.

When rolling back

Netlify allows you to rollback to a previous production deploy, in case you have determined that the currently published deploy is faulty in some way. This is performed by manually publishing a previous deploy.

When you rollback to a previous deploy, Netlify does not automatically restore the database from an on-publish backup. The production branch of your database remains intact, with its current data and schema.

It is up to you to decide if you want to restore any of the available backups. To learn more, read: Should I restore a backup?.

When auto-publishing is locked

If you lock a deploy to stop auto-publishing, any subsequent production deploys are not automatically published, allowing you to manually publish any production deploy at a time of your choosing - typically, publishing a newer deploy (or, rolling forward).

In that mode, the automatic on-publish backup is taken only when you manually publish a deploy, not when it was built. This is because only at publishing does a deploy start serving your primary domain (your live site), and any pending migrations are run.

Note that for projects that have a database provisioned, Netlify does not allow manually publishing a deploy preview directly (which is a shortcut that skips the step of merging its code into production branch first) - you can only manually publish another production deploy. To get a deploy preview published, merge its code into your production branch first - which is the typical and safe way to do it.

Backup retention

Backups are retained based on your Credit-based pricing plan.

The retention mechanism depends on the type of backup:

• On-schedule backups are kept for a fixed amount of days.
• On-publish backups are kept for up to a fixed amount of previous backups - so the time duration they are kept for depends on the frequency of publishing a project to production.

Plan	On-schedule backup retention	On-publish backup retention
Free	3 days	Backup of the most recently published deploy only
Personal	7 days	Backups of last 3 deploys
Pro	30 days	Backups of last 10 deploys
Enterprise	30 days	Backups of last 10 deploys

Restore a backup

Should I restore a backup?

Restoring from a backup is the best way to get a database to exactly the shape it was when the backup was taken. This includes both the database schema (i.e. its structure: tables, columns, etc.) and its data. However, any changes in data or structure that have occurred after the time of the backup are lost when restoring.

To determine whether this is problematic to you or not, consider two scenarios:

If your project has not yet gone live for its end users, or sees very intermittent usage (which is common for e.g. internal apps):

The decision to restore is easier: there are no or very few meaningful changes to the database from the time the backup was taken. If your database troubles started due to a faulty deploy, you would probably want to roll back to a previous deploy as well.

However, for a live web app that sees continuous usage by end users, restoring from a backup means the deletion of any user activity recorded to the database between the time of the backup and the time when you perform the restore. In this case, restoring from backup is usually the last resort - and customers prefer to prepare & deploy targeted fixes to the code and/or the database schema instead.

Please keep the following in mind:

1. If you are not sure whether to restore a backup or not, please contact Netlify support.
2. Netlify provides a fail-safe mechanism: when restoring from a backup, a dedicated branch is created that preserves the production branch contents just prior to the restore. You can view the contents of this branch via the UI. To inquire about reverting a restore using this branch, contact support.

To restore a backup, you must have the Team Owner role.

Follow these steps:

1. From your project dashboard, on the left, select Database.
2. Scroll to Backups, and next to the backup you want to restore, select Restore and confirm.