Quick answer: Database backup for VPS or Cloud Server should not mean only a nightly dump. For PostgreSQL, MySQL or business-critical ERP and website databases, define RPO/RTO, keep full backups, preserve transaction logs for point-in-time recovery when needed, store an offsite copy, alert failed jobs and run scheduled restore tests. If no restore has been tested, the backup is still only an assumption.
Why database backup is different from website file backup
Website files usually change during deployment, media upload or plugin updates. A database changes continuously: orders, customers, inventory, invoices, application logs, user accounts and business settings. A clean file backup with a database that is several hours behind can still mean lost orders, wrong stock or manual data re-entry.
For business Cloud Server/VPS, the better question is not simply whether backup exists. The real questions are how much data the business can lose, how quickly the system must be restored, whether it can return to a specific moment and who validates the data after recovery.
RPO, RTO and PITR explained
| Concept | Business meaning | Question to answer |
|---|---|---|
| RPO | Maximum acceptable data loss | Can the business lose 15 minutes, 1 hour or 1 day of data? |
| RTO | Maximum acceptable recovery time | Can the system be down for 30 minutes, 2 hours or a full day? |
| PITR | Recover to a specific point in time | Can we restore to just before the wrong import at 10:35? |
| Retention | How long backups are kept | Should backups be kept for 7, 30, 90 days or longer? |
PostgreSQL point-in-time recovery is based on a base backup combined with archived WAL files. MySQL point-in-time recovery commonly combines a full backup with binary logs. The shared lesson is simple: one full backup is not enough when the business needs recovery close to the incident time.
When does a business need PITR?
- E-commerce websites with orders, payments, inventory or customer data changing throughout the day.
- Odoo, ERP, accounting or inventory systems using PostgreSQL or MySQL.
- Internal applications where accidental deletes or bad updates are hard to reverse.
- Large databases where taking full backups very frequently is impractical.
- Systems that may need recovery to just before a bad import, script error or user mistake.
- Businesses that need audit evidence and clear data-responsibility reporting.
Recommended database backup model
| Protection layer | Role | Note |
|---|---|---|
| Full backup | Recovery baseline | Daily or weekly depending on size and maintenance window |
| Transaction logs | Recover closer to incident time | PostgreSQL WAL or MySQL binlog must be stored and monitored |
| Server snapshot | Fast infrastructure rollback | Useful, but not a replacement for database-aware backup |
| Offsite copy | Protect against server or storage failure | Keep it outside the production machine |
| Restore test | Prove backup is usable | Record restore time, data completeness and application startup |
The 3-2-1 backup rule remains a useful baseline: multiple copies, more than one storage type and at least one offsite copy. For important databases, add failed-job alerts, log growth monitoring and strict access control for backup files.
Common database backup mistakes
- Dumping the database every night but forgetting ERP filestore or attachments.
- Keeping backup on the same production disk, so one storage issue can affect both data and backup.
- Not monitoring WAL or binlog retention, then discovering that PITR logs are missing.
- Running backup during peak hours without monitoring performance impact.
- No documented restore runbook: who restores, where, what to validate and how long it takes.
- Too many people can delete backup files or access sensitive data.
- Checking that a backup file exists, but never testing a real restore in a separate environment.
Special notes for Odoo and ERP databases
Odoo and many ERP systems use PostgreSQL, but business data is not only inside the database. Filestore, custom modules, worker configuration, reverse proxy, email settings, cron and software versions all affect recovery. Restoring only the database may bring back orders while losing attachments, invoices or documents.
If you are choosing an ERP server, also read Cloud Server for Odoo, ERP and database workloads. It explains when to use VPS, when to split the database and when to move toward Dedicated Server or Private Cloud.
Checklist before choosing a Cloud Server package
- Database engine: PostgreSQL, MySQL/MariaDB, MSSQL or another platform.
- Current size, monthly growth and peak transaction hours.
- RPO/RTO for each system: website, ERP, internal app or accounting database.
- Whether PITR is required or daily full backup is enough.
- Where backup is stored: local disk, snapshot, NAS, object storage, cloud backup or offsite copy.
- Need for encryption, download/delete restrictions and access logging.
- Restore-test schedule and the person who validates data after recovery.
Recommended next pages
If you are still sizing infrastructure, review VPS configuration advice and VPS Cloud pricing. If you have workload details ready, use the Cloud VPS order page. If backup is the main requirement, see Cloud Backup for business.
Frequently Asked Questions
Do I still need database backup if I already have VPS snapshots?
Yes. Snapshots are useful for infrastructure rollback, but database-aware backup is needed for point-in-time recovery, data validation and migration to another environment.
Does every website need PITR?
No. A low-change website may be fine with daily backup. PITR matters more for transaction databases, ERP, WooCommerce, internal applications and systems with constant data updates.
How often should restore be tested?
For important systems, test at least quarterly and after major changes such as server migration, database upgrade, backup job changes or significant data growth.
Database backup advice
Need database backup/PITR for Cloud Server?
IT Systems can review PostgreSQL/MySQL, RPO/RTO, offsite backup and restore-test requirements, then recommend a VPS/Cloud Server backup design with lower data-loss risk.
