Undo an accidental change: restore a file, setting, or database safely

TL;DR — If you changed something by accident, the fastest safe fix is: first use your product's built-in Undo, Version History, or Activity Log in the dashboard; if that is not available, restore the last known good version from backup. Do not keep making more edits while you investigate, because extra changes can overwrite the exact version you need to recover. Reading time: ~5 min

Goal

When you finish, the accidental change is reversed and the affected page, file, setting, or data looks and behaves the way it did before the mistake.

Prerequisites

• Access to the product's dashboard or admin area with permission to edit content, settings, or restore backups
• The approximate time the accidental change happened
• The name of the thing that changed: page, file, setting, record, or database table
• If your product has version history or backups: permission to view restore points
• If your agency gave you Git access (Git = version control, a history of file changes): the repository URL and a GitHub/GitLab/Bitbucket login
• If your agency gave you server or database access: the exact environment name, such as production or staging

Steps

Step 1: Stop new edits on the affected item

If other people can edit the same content, ask them to pause until the restore is complete.

Exact action in the dashboard: open the affected page, file, or setting and do not click Save again.

What you should see when this succeeds: no new timestamps or "last edited" updates appear while you work.

Step 2: Try the built-in Undo or Version History first

In your provider's dashboard, open the affected item and look for one of these exact labels:

• Edit → Undo
• History → Version history
• More actions → Activity log
• Settings → Audit log

If your provider shows a list of versions, choose the last version from before the accidental change, then click:

• Restore this version
• or Revert to this version

What you should see when this succeeds: the page preview, setting value, or content matches the earlier version, and the dashboard shows a new "restored" or "reverted" entry.

Step 3: If it was a website file change, restore the previous file version

If the accidental change was code, template text, CSS, or a config file, use your code host's history.

In your code host dashboard, open the repository, then use one of these common paths:

• GitHub: Repository → File → History
• GitLab: Project → Repository → Files → History
• Bitbucket: Repository → Source → File → History

Open the version from before the mistake and use the UI action to restore or copy its contents back into the current file.

If you were given command-line access instead, use these exact commands in the repository folder:

git log --oneline -- path/to/file

Copy the commit ID from before the accidental change, then run:

git restore --source=<COMMIT_ID> -- path/to/file

To save that restore as a new change:

git add path/to/file
git commit -m "Restore path/to/file to state before accidental change"

What you should see when this succeeds: the file contents match the earlier version, and any preview or diff shows the accidental edits removed.

Step 4: If it was an app setting, put back the previous literal value

For a changed setting, use the audit log or change history to find the old value, then re-enter that exact value.

Common dashboard paths are:

• Settings → Audit log
• Admin → Activity
• Project settings → Change history

Find the entry from the time of the mistake. Copy the previous value shown in the log, then go back to the setting and paste that exact value into the field. Click:

• Save
• or Update

What you should see when this succeeds: the setting screen shows the old value again, and the application behavior returns to normal after refresh.

Step 5: If data was changed or deleted, restore from backup to a safe place first

⚠️ Restoring a database directly over your live database can overwrite newer good data and cause downtime. If your dashboard offers "restore to new database" or "restore to point-in-time to a new instance," use that first.

In your hosting or database provider dashboard, look for one of these paths:

• Database → Backups → Restore
• Project → Backups → Point-in-time restore
• Instances → Backups → Restore to new instance

Choose the backup from just before the accidental change. If the dashboard offers a destination, select:

• Restore to new database
• or Restore to new instance

After the restore finishes, compare the missing or changed records in the restored copy with production, then copy only the needed records back using your provider's table editor or import/export tool.

If you only have PostgreSQL command-line access and a SQL dump file, restore to a new database with these exact commands:

createdb restore_check
pg_restore -d restore_check /path/to/backup.dump

What you should see when this succeeds: the restored copy opens without errors, and you can see the missing or previous data in the backup copy.

Step 6: If the accidental change was deployed to the live site, roll back the deployment

In your hosting or deployment dashboard, look for one of these paths:

• Deployments → Previous deployment → Redeploy
• Releases → Select previous release → Roll back
• Activity → Deploy history → Promote previous build

Choose the last deployment from before the issue started.

If your deployment is Git-based and you were given CLI access, find the last good commit and revert the bad one:

git log --oneline

Then run:

git revert <BAD_COMMIT_ID>

Push the revert if your workflow requires it:

git push

What you should see when this succeeds: the deployment history shows a new rollback or revert deployment, and the live site behaves like it did before.

Verify it works

Check the exact thing that was broken before.

For a page or website change:

• Open the affected page in a private/incognito window.
• Refresh once with a hard reload.
• Confirm the old text, layout, image, or behavior is back.

For a setting change:

• Return to the setting screen.
• Confirm the field shows the previous value.
• Test the feature that was failing before.

For a database restore:

• Open the affected record in the app.
• Confirm the missing or changed data is present.
• Check one newer record too, so you know you did not overwrite recent good data.

If you have a URL to test, use this command and expect a normal success response such as 200 OK or a redirect you recognize:

curl -I https://your-domain.example/path

Expected result:

HTTP/2 200

or, if the page normally redirects:

HTTP/2 301
location: https://your-domain.example/final-path

Common pitfalls

Restoring directly over production instead of to a copy first

Mistake: choosing "restore" without checking whether it replaces the live database.

Symptom: newer customer data disappears after the restore.

Fix: use Restore to new database or Restore to new instance, compare data there, then copy back only what you need.

Clicking Save again before checking history

Mistake: opening the broken item and saving it while trying to inspect it.

Symptom: the bad version becomes the newest version, which makes history harder to read.

Fix: stop editing, open History, and restore the last version from before the extra save.

Reverting the wrong commit

Mistake: picking a commit by date alone instead of checking the changed files.

Symptom: the site changes, but not in the way you expected, or a different feature breaks.

Fix: open the commit diff first and confirm it includes the exact file or feature you need to undo, then run git revert <BAD_COMMIT_ID>.

Browser cache making it look like the rollback failed

Mistake: checking the site in the same browser tab after a restore or deployment rollback.

Symptom: you still see the old broken page even though the dashboard says the restore succeeded.

Fix: open the page in a private/incognito window or do a hard refresh, then test again.

Restoring a backup from after the mistake

Mistake: choosing the latest backup instead of the last known good backup.

Symptom: the restored copy still contains the accidental change.

Fix: use the timestamp from the audit log or activity feed and choose a backup from just before that time.

Fixing production before confirming the cause in logs or history

Mistake: changing multiple settings quickly to "try things."

Symptom: it becomes unclear which change caused the issue, and rollback takes longer.

Fix: check Activity log, Audit log, or Version history first, identify the exact change, then revert only that change.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.