Skip to main content

Storage Planning

Storage planning prevents backup systems from failing silently. Before you automate anything, estimate how much data you will generate, how long you will keep it, and how fast you can move it offsite.

Quick Summary
  • Plan for both artifacts: WordPress files + database.
  • Estimate compressed size, then multiply by retention.
  • Account for offsite copies and restore time.
  • Reserve headroom so backups do not fill the VPS disk.

What you are backing up​

For WordPress, the minimum is:

  • Files: WordPress root (especially wp-content/).
  • Database: MySQL/MariaDB dump.

Optionally:

  • Server config: nginx/apache config, PHP-FPM pool configs, cron jobs.
  • Secrets: .env and wp-config.php (handle carefully).

Measure current size​

measure-wordpress-files-size.sh
sudo du -sh /var/www/html
sudo du -sh /var/www/html/wp-content

Database size (approximate):

estimate-database-size.sh
mysql -e "SELECT table_schema AS db, ROUND(SUM(data_length+index_length)/1024/1024,1) AS mb FROM information_schema.tables GROUP BY table_schema ORDER BY mb DESC;"

Estimate compressed size​

Compression depends on content:

  • Images/video are already compressed (limited gains).
  • Text, SQL dumps, and logs compress well.

As a rough rule:

  • SQL dumps: often 4x to 15x smaller with gzip/zstd.
  • WordPress files: depends on media volume; theme/plugin code compresses well, uploads compress poorly.

If you want a quick experiment (small sample):

sample-compress-test.sh
tar -C /var/www/html -cf - wp-content | zstd -3 -T0 -o /tmp/wp-content.sample.tar.zst
ls -lh /tmp/wp-content.sample.tar.zst

Retention math you can reuse​

Write down:

  • F = average compressed files backup size
  • D = average compressed database backup size
  • N = number of daily backups kept
  • W = number of weekly backups kept
  • M = number of monthly backups kept

Then estimate storage:

  • Daily: (F + D) * N
  • Weekly: (F + D) * W
  • Monthly: (F + D) * M

Add headroom (at least 30%) for growth.

Bandwidth and time windows​

If offsite copies take longer than your backup window, you will build a backlog.

Check outbound bandwidth:

bandwidth-smoke-test.sh
curl -fsS https://speed.hetzner.de/100MB.bin -o /dev/null

Make backups less disruptive:

backup-offpeak-with-priority.sh
nice -n 10 ionice -c2 -n7 tar -C /var/www/html -czf "/backups/wp-files-$(date +%F).tar.gz" .

Storage types (what to use)​

Local:

  • Same disk: fastest, but least safe.
  • Separate mounted volume: better isolation (still same VPS).

Offsite:

  • Another VPS: easy restores, you manage disks.
  • Object storage (S3/R2/B2): durable and scalable, restore requires download.
  • Cloud drive: convenient but can be throttled and less automation-friendly.

Next steps​

  • Retention policies: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/rotation--retention-policies.mdx.
  • Offsite redundancy: opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/offsite--local-redundancy.mdx.