New format
Website databases: organization and backup
A site isn’t only HTML and images. Most live data — products, orders, users, CMS settings — sits in a database. Losing theme files hurts; losing the DB with no backup often means losing business history.
Below: how the DB relates to site files, why it exists, what can go wrong, and how to approach backups without the “once a year on a USB stick” habit.
What a site database is
A database (DB) is structured storage: tables, rows, relations. The CMS reads and writes content and service data there; the web server returns assembled pages to the user.
Analogy: a car catalog in tables (model, power, color) with filters and links. Same way a store keeps products and orders, a blog — posts and metafields, a portal — users and permissions.
Usually the DB holds:
- content records (pages, posts, cards)
- users and roles
- CMS and plugin settings
- orders, carts, forms (if not moved to external services)
- service queues, app logs (depends on the stack)
Files and DB: two layers of one site
Theme code, plugins, `uploads` with images — filesystem. Product texts, prices, order status — usually the DB. Media often also has metadata in the DB (WordPress attachments and peers).
When moving hosts you copy both layers and fix access (DB login, table prefix, URLs in options). One layer without the other gives a white screen or a site with no content.
Before migration:
- DB dump + file archive
- compatible PHP/MySQL versions
- secrets and `.env` not in a public archive
- a plan to check forms, payment, and account after the move
Why a site needs a DB in practice
Without a DB a dynamic site becomes static files: hard to edit a thousand cards, filter, track stock, manage users. The DB gives queries, relations, and point updates.
The cost of convenience is responsibility: schema mistakes, full disks, SQL injection in vulnerable code hit the data. Update code and plugins; limit DB access; verify backups by restoring.
Risks:
- tables deleted/corrupted on a bad update
- hacks and ransomware
- host disk failure
- human error in phpMyAdmin
- revision and junk-table bloat → slowdowns
Organization: prefixes, permissions, performance
On shared hosting often one MySQL database per site; table prefix is set at CMS install. Don’t give the app root access: a separate DB user with rights only on the needed database.
Performance: indexes, object/page cache, cleaning revisions and transients, sane limits. A heavy DB shows as timeouts and a slow admin — that’s engineering and hosting, not “one more SEO plugin.”
Hygiene:
- strong DB passwords, not the same as admin
- limit remote MySQL access
- monitor DB size and slow queries
- don’t keep production dumps in `public_html`
Backup: what and how
A DB backup is usually an SQL dump (or a volume snapshot from a cloud provider). A file backup is a code + uploads archive. Full restore = both + environment secrets.
Take copies before CMS/plugin updates and major catalog changes. Keep several restore points (e.g. day / week), not one overwriteable “latest.”
Backup checklist:
- what’s included: DB + files + who owns it
- schedule and retention
- storage off the same disk
- restore test on staging at least quarterly
- encrypt sensitive dumps in transit
Tie-in with SEO and stability
Search needs availability and predictable server responses. Outages from the DB, 5xx errors, and endless page generation hurt crawl and conversion more than a small meta tag.
Duplicates, pagination, and canonicals are about URLs and templates; the DB only stores content. If the site is down or responds in minutes — stability and backups first, fine semantics later.
Practical order:
- live availability monitoring
- current backups with a test
- CMS updates and access control
- then the finer SEO layer
FAQ
How does a database differ from files on hosting?
Files are code, templates, media. The DB is structured records: posts, SKUs, orders, options. Recovery needs both layers.
Which database systems do sites use most?
Classic CMSs — often MySQL/MariaDB. PostgreSQL and others appear; follow CMS and hosting docs.
Is a files-only backup enough?
No. Without a DB dump you restore an empty or stale shell without orders and content.
How often should you back up?
Depends on change rate: a store with orders — more often (daily/hourly); a brochure site — less. Critical: a fresh copy before CMS updates and migrations.
Where should you store copies?
Not only on the same server disk. Need a second layer: another host, object storage, company policy — with a restore test.
If the host backs up, can you stop thinking about it?
Handy as insurance, but check retention, what it includes (files+DB), and whether you can restore yourself. Don’t rely blindly.
Does the database affect SEO directly?
Indirectly: slow queries and outages cut UX and crawl. Content duplicates are more about URLs and templates than table names. Tech audit and logs are sibling topics.
Can you edit the database by hand in phpMyAdmin?
Only if you understand the schema and have a fresh backup. A typo in the orders table costs more than an edit via the CMS admin.
CMS update tomorrow — and the only backup is “files on the same disk”?
We’ll set DB+files backups offsite and a restore test — before the next migration.
Discuss the task
