Database Backup & Recovery Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A backup is proven by a restore

A backup you have not restored is a file you hope is good. This page is the plan: what is copied, how often, where it sits, and the last time a restore onto a lab actually finished. The strategy planner drafts those headings. The dump builder drafts a command. You read both. Neither one logs into the database.

A logical dump and a physical copy are different tools. A dump is portable and slow to restore when the database is large. A physical copy is fast and fussy about versions. Write which one you are testing. Do not mix them in one window and call both done.

The restore target is a lab, an empty instance, or a named copy. It is not the production data directory. Overwriting production to see whether the backup works is how a test becomes the incident. The system desk's backup guide is the host and the disk. This page is the database.

Retention is a number of copies and a place. A single file on the same disk as the database is not a backup against a dead disk. Say where the second copy lives. Secrets in the dump are still secrets. The file is not world-readable.

One lab dump, one lab restore, one clock time

On the lab, take the dump the builder drafted after you have read it. Note the start time and the size. Restore it onto a second lab database whose name is obviously a restore. Count a table you know. The count matches.

Write the elapsed time. That time is the beginning of a downtime conversation, not the whole of it. The migration and availability guides need this number. A number you guessed is labelled as a guess.

If the command includes a password, replace it with prompt-for-this and take the real value from the store or from a prompt. A password in the shell history is a password you rotate.

Schedule the next restore test. A test from a year ago is a story. The ticket has a date.

# Lab backup. Review before you paste.
# Restore onto a second lab name, never onto production.
# prompt-for-this is not a password in the command or the history.
# Record start, finish, size, and a table count.
# The dump file is not world-readable.

A change you can finish

Production backup jobs change only after a lab restore has a time and a count. Turning on a job you have never restored is not this window's success.

Rollback of a bad restore is dropping the lab copy. Production was not the target, so production does not need a rollback from this test.

Name the database, the method, and the destination.
Read the drafted command. Remove embedded passwords.
Dump the lab. Record size and time.
Restore onto a different lab name.
Count a known table.
Write the elapsed time in the ticket.
Date the next test. Keep the dump restricted.

Mistakes that outlive the command

database backup and recovery fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

A backup that has never been restored.
Restoring over production to test.
A password in the command line.
A dump on the same disk called a disaster copy.
A world-readable dump file.
Logical and physical backups changed in one window.
A guessed restore time treated as a measurement.
No table count after the restore.
Testing with a customer extract you were not supposed to copy.
No date for the next test.

Decisions to write down before the window

One decision for database backup and recovery: The method is dump or physical, and you named one. The restore target is a lab name, not production. The command was read. No password sits in it. Size, start, and finish are written. A known table count matches. The dump is not world-readable. A second copy destination is named, or its absence is a gap. The elapsed time is a measurement. The next test has a date. The availability guide can use this time. It does not replace the test. The system backup guide owns the host disk. And one database is this window.

The hour you stop

Write the database name, the host, and the clock time before you change anything for database backup and recovery. If this database is serving people and you do not have a copy, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a restored copy. The rows you read are rows you are allowed to hold. You do not point a client at a database, a cluster, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a connection string, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A config line, an index, a grant, and a restore do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file or the backup you already tested.

A second person reads the scope aloud: which host, which database, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

The lab listens on localhost. 127.0.0.1 is the address you bind until a firewall story exists. example.com is not your host. A generated file that listens on every address is a file you edit before it runs.

Do not run a statement you cannot undo. A delete or a drop without a backup and a where-clause you have read is the mistake this page is here to prevent. Read the statement. Count the rows it will touch. Then decide.

Keep the previous config and the previous dump. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the reload with a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a database nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next database waits until someone else can repeat the proof from the notes. database backup and recovery is done for this window when the proof is written, not when the client printed a prompt.

This page is a planning guide. It is not a vendor manual, not an official standard, and not legal advice. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this database alone until that guide has its own window.

Backup checks before you trust the job

Confirm this before you call the change done: The lab restore finished. The target name was not production. The table count matches. Elapsed time is in the ticket. The dump location is written. The file mode is restricted. No password is in the history you kept. The method is named. A second person saw the count. The next test is dated. Production data files were not replaced. The command in the ticket matches the command you ran. The hostname in the prompt matches the hostname in the ticket for database backup and recovery. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for database backup and recovery happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: System: Backup & Recovery Guide.