What Is a Database Backup?

Why a Website Needs Its Own Database Backup

A database backup is a copy of the structured data a website relies on, such as posts, orders, customer accounts and settings. Files alone are not enough. Most dynamic sites keep their content in a database, and the files only describe how to display it.

A database changes constantly. A shop records orders while visitors browse, and a forum adds replies every minute. A file backup from one time and a database backup from another may not match, which can cause errors when both are restored together. This is why the database is usually backed up as its own item, with its timing planned separately. The full list of parts is in what to include in a website backup.

Logical Dumps and Physical Backups Compared

There are two main ways to copy a database.

• Logical dump exports the database as a set of statements or data files that can recreate its tables and rows. It is portable and easy to inspect, and it can often be restored onto another system. It is slower for large databases, and restoring can take a long time.
• Physical backup copies the database's underlying files or storage pages. It is faster for large databases, but it is more closely tied to the database engine and version.

Both approaches are valid. The choice depends on database size, how quickly you need to restore, and whether the copy must move to a different system.

Why Copying Live Database Files Can Fail

Consistency means the backup reflects one coherent state of the database. Copying raw data files while the database is running is risky. The engine may be partway through writing a change, so one file shows the new state while another still shows the old one. The result can be a backup that looks complete but will not start, or that starts with damaged tables.

A safer approach is to use a method that asks the database to produce a consistent copy, such as a dump made through the database's own tools. Server-level snapshots can also miss a busy database's in-progress writes, so they should not be the only protection for a busy database. Timing matters too: the more often data changes, the more often a copy is needed.