How to Back Up Your Server Files and Database (Before You Learn the Hard Way)

Chibuike Okoye — Fri, 05 Jun 2026 20:34:21 +0000

There is a special kind of silence that hits you the moment you realize your data is gone. No database. No uploads. No .env. Just an empty folder where two years of work used to live.

I have felt it. Most developers feel it exactly once, because once is enough to make you religious about backups for the rest of your life.

This is the short, practical guide I wish someone had handed me before that day. No theory you will never use. Just how to back up your project files and your database properly, on a schedule, somewhere safe, so a dead server is an annoyance instead of a funeral.

The one rule that actually matters: 3-2-1

You will see it everywhere because it works.

3 copies of your data
2 different places
1 of them off the server

Most people get the first two by accident and miss the one that counts. A backup sitting on the same server as your live site is not a backup. It is a second copy waiting to die in the same crash, the same hack, the same accidental rm -rf, the same suspension. If your backup can be deleted by whatever kills your server, it was never real.

Off-site is the whole game. Everything below builds toward it.

Step 1: Back up the database the right way

Files you can usually re-download or rebuild. The database is the irreplaceable part. It is your users, your orders, your content, the actual value of the thing. Start here.

MySQL or MariaDB:

mysqldump --single-transaction --quick --routines \
  -u youruser -p yourdatabase | gzip > db-$(date +%F).sql.gz

The flags matter more than they look. --single-transaction takes a clean, consistent snapshot without locking your tables, so your live site keeps running while the dump happens. --quick streams rows instead of loading the whole table into memory. gzip shrinks a text dump by ten times or more.

PostgreSQL:

pg_dump -U youruser -Fc yourdatabase > db-$(date +%F).dump

The -Fc custom format is already compressed and lets you restore selectively later.

Test the restore now, not during a fire. A backup you have never restored is a rumor, not a backup.

gunzip -c db-2026-06-05.sql.gz | mysql -u youruser -p a_scratch_database

If it loads into a throwaway database cleanly, you have a real backup. If it errors, you just found out today instead of on your worst day.

Step 2: Back up the files that cannot be regenerated

Do not tar up your entire server. Most of it is reinstallable. Back up the parts that are truly yours:

User uploads and media (storage/app, wp-content/uploads, your public upload dirs)
Config and secrets (.env, wp-config.php, anything with keys in it)
Custom code that is not already in git
Your email, if it lives on the same server. Mail is just files: your inbox sits in a maildir, often under your home or /var/mail. Back that folder up and a wiped mailbox becomes recoverable instead of gone.

tar -czf files-$(date +%F).tar.gz \
  storage/app \
  .env \
  public/uploads

Skip the noise. Your node_modules, vendor, and framework core are a composer install or npm install away. Backing them up just makes the archive huge and slow for zero benefit.

Step 3: Automate it, because you will forget

A backup you have to remember to run is a backup that will not exist the week you need it. Put it on a schedule and walk away.

Drop your dump and tar commands into a small script, then add one cron line:

# back up every night at 2am
0 2 * * * /home/youruser/backup.sh >> /home/youruser/backup.log 2>&1

That log on the end is not optional. A silent cron job that quietly broke three weeks ago is how people end up with a folder full of zero-byte files. Log it, and glance at the log once in a while.

Step 4: Get it off the server

This is the step everyone skips and everyone regrets. A backup on the same box is gone the moment the box is gone. Push it somewhere with no connection to your hosting account: object storage, a different provider, anywhere the failure of your server cannot reach.

If you are on raw cloud storage, that means wiring up credentials, install tooling, lifecycle rules, and praying you never leak a key that has write access to everything you own. It is doable. It is also a lot of moving parts to get right and keep right, forever, for every server you run.

Which is the honest reason I eventually stopped doing it by hand.

The shortcut: let an agent do all four steps

I run CodedHost, and the thing I kept wishing existed is the thing we ended up building: a small agent you drop onto any server that does every step above on its own.

You install it with one line, point it at your databases and folders once, and from then on it dumps, compresses, and ships an off-site copy every night without you touching it. It runs on a full root VPS and on shared hosting like cPanel or Namecheap where you have no root at all. It does not even matter what your site is built with.

curl -fsSL https://codedhost.vip/agent/install.sh | $(command -v sudo) bash -s -- <your-agent-id> <your-secret>

The part I care about most: the storage is completely separate from your hosting. The agent never holds the keys to it. Each run it checks in, gets a one-time upload link good for a few minutes, ships the file, and the link expires. Nothing permanent sits on your server to leak. And because the backup lives somewhere independent, it is still there and still downloadable even on a day your host suspends you, or our own site is having a bad time. Your data does not depend on anyone's uptime, including ours.

When you need it back, it hands you the file and gets out of the way. It will never reach into your live database and overwrite it on a guess. You restore, on your terms.

That is the whole idea: 3-2-1 done for you, including the off-site copy that is the only part that ever really saves you.

You can read exactly how it works, or grab it, here: codedhost.vip/server-backup

The one-line version

Back up your database with --single-transaction. Back up only the files you cannot regenerate. Put it on cron with a log. And get a copy off the server, because the copy that lives somewhere else is the only one that will ever save you.

Do it by hand or let something do it for you. Just do not be the person learning this lesson the expensive way. I already took that one for you.

DEV Community: Chibuike Okoye