Coder Legion - Recent posts tagged backup

rsync's dangerous flags don't fail. They do a different job and exit 0.

Tue, 20 Oct 2026 13:00:00 +0000

The trap with rsync is that its dangerous flag combinations don't fail — they complete a different operation than the one you intended, and exit 0. --delete makes the destination match the source, so a mistyped or freshly moved source directory means rsync removes everything at the destination and reports success. Your cron log shows a clean run while the backup empties itself. A trailing slash changes the meaning too: /data/ syncs the directory's contents, while /data copies the directory itself into the destination — and on a mirror job, that difference decides what gets compared and what gets deleted.

The defense is previewing every destructive sync before running it live:

rsync -av --delete --dry-run /srv/www/ user@backup:/srv/backup/www/

Read the deleting … lines it prints; only when that list matches your expectations do you remove --dry-run. Note also that excludes take one pattern per flag — --exclude='*.log' --exclude='.git' — because a comma-separated list inside a single flag silently matches nothing.

If you'd rather compose the command with those guardrails enforced — a red warning when --delete is enabled without a dry run, per-pattern quoted excludes, and a live preview of the finished command — I built a visual rsync command builder with delete-flag guardrails that runs entirely in the browser.

How to Back Up and Restore Self-Hosted n8n

Mon, 12 Oct 2026 15:50:00 +0000

A recoverable self-hosted n8n backup has four core parts: the database, the original encryption key, the deployment configuration and secrets, and any binary-data storage your executions still need. Back up the persistent .n8n volume even when PostgreSQL stores the main database. n8n documents that this directory can still contain the encryption key, logs, and source-control assets.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

Short answer: workflow JSON files alone are not enough. They do not recreate the complete instance state, and encrypted credentials are unusable without the key that encrypted them.

What must be in the backup

Asset	Why it matters	Typical location
Database	Workflows, encrypted credentials, users, projects, settings, and retained execution data	`~/.n8n/database.sqlite` or PostgreSQL
Encryption key	Decrypts the credentials stored in the database	`~/.n8n` settings or `N8N_ENCRYPTION_KEY`
Deployment config	Restores database connection, public URL, proxy, timezone, pruning, and execution behavior	Compose file, environment settings, secret references, proxy config
Binary data	Restores retained files handled by executions when filesystem or external storage is used	Persistent filesystem, database, or configured external store
Custom and community nodes	Allows restored workflows to load the same node types and versions	Package list, custom-node directory, container image, or build manifest

Do not put the raw encryption key, database password, OAuth secrets, or an unredacted environment file in a public repository. Keep a sanitized deployment definition in version control and protect the actual secrets in a restricted password manager, secret store, or encrypted backup.

Choose the database path before writing the runbook

Self-hosted n8n uses SQLite by default. The database file is ~/.n8n/database.sqlite. PostgreSQL is the other supported database option. The backup and restore commands must match the database your instance actually uses.

SQLite: capture a consistent persistent volume

The simplest small-instance method is a short maintenance window: stop the n8n application, archive its persistent volume, then start it again. Stopping writes avoids treating an arbitrary live file copy as a consistent database backup. For the standard Docker volume shown in n8n's installation guide, a generic sequence looks like this:

docker compose stop n8n
docker run --rm \
  -v n8n_data:/data:ro \
  -v "$PWD/backups:/backup" \
  alpine tar czf /backup/n8n-data-2026-07-18.tgz -C /data .
docker compose start n8n

Replace the service and volume names with the names in your deployment. If downtime is not acceptable, use a storage snapshot or SQLite-aware backup process that guarantees a consistent result. Do not assume that copying database.sqlite while executions are writing to it is safe.

PostgreSQL: use a database dump

PostgreSQL's official documentation recommends pg_dump for logical backups. A custom-format dump works with pg_restore and is practical for restoring into a fresh database. Adapt the connection values and run the tool from a host or database container that can reach PostgreSQL:

pg_dump --format=custom --file=n8n-2026-07-18.dump n8n

The dump does not replace the n8n persistent volume or explicit encryption key. It also does not capture the Compose file, environment settings, proxy configuration, or filesystem binary data. Store those as separate parts of the same dated backup set.

Add native n8n exports as a second recovery layer

n8n's Server CLI can export all database entity types. Its documentation positions this tooling for backups and migrations, including moves between SQLite and PostgreSQL. Execution-history data tables are excluded by default because they can be large, and can be included explicitly when your retention requirement needs them.

docker exec -u node n8n \
  n8n export:entities \
  --outputDir=/home/node/.n8n/cli-backup

Workflow and credential exports are also useful for selective recovery or versioned copies:

n8n export:workflow --backup --output=backups/workflows/
n8n export:credentials --backup --output=backups/credentials/

Avoid decrypted credential exports for routine backups. n8n supports a --decrypted flag for migrations to a different secret key, but the resulting files expose every sensitive value in plain text. If that exceptional path is necessary, isolate, encrypt, restrict, and delete the files after the migration.

A safe restore runbook

First restore into an isolated instance with no production webhooks, schedules, email sends, payment calls, or CRM writes. The first recovery test should never overwrite the only production copy.

Record the target. Use the same n8n version first, the same database type, and compatible custom-node versions. Upgrade only after the restored instance works.
Create fresh infrastructure. Prepare a new Docker volume or empty PostgreSQL database rather than clearing production.
Restore the original encryption key. Put the protected N8N_ENCRYPTION_KEY or original n8n settings in place before n8n reads the restored credentials.
Restore the database. Extract the stopped SQLite volume archive into the new volume, or restore the PostgreSQL dump into the new database.
Restore the surrounding state. Reapply deployment settings, binary storage, custom nodes, public URL settings, and reverse-proxy configuration.
Start without production traffic. Keep DNS, proxy routing, and outbound side effects isolated while checking startup and migration logs.
Verify the application. Confirm login, projects, workflows, credentials, node availability, execution history required by policy, and binary files that should still exist.
Run one safe test. Use test credentials or a non-destructive workflow and confirm that a credential can decrypt and authenticate.
Publish deliberately. Review which workflows should be published before switching traffic. Imported workflows can have different active-state behavior depending on the import path and deployment mode.

Restore a SQLite archive into a new volume

A new volume keeps the original recoverable while you inspect the restore. This example extracts the archive created above without deleting the production volume:

docker volume create n8n_restore_data
docker run --rm \
  -v n8n_restore_data:/data \
  -v "$PWD/backups:/backup:ro" \
  alpine tar xzf /backup/n8n-data-2026-07-18.tgz -C /data

Point a separate restore Compose file at n8n_restore_data. Do not bind it to the production hostname or webhook route until the checklist passes.

Restore PostgreSQL into a fresh database

createdb n8n_restore
pg_restore --dbname=n8n_restore n8n-2026-07-18.dump

Real deployments may need explicit host, user, role, ownership, TLS, and schema options. Test the exact command your operator will use and document it beside the backup job without embedding the password.

Restore-test checklist

The backup job has a timestamp, size, success state, and failure alert.
The database and encryption key come from the same recoverable setup.
The restore starts on a separate hostname, volume, and database.
Credential nodes open without decryption errors and one test authentication succeeds.
Required custom or community nodes load at the expected versions.
Published workflows, schedules, and webhook paths are reviewed before traffic moves.
Required retained binary files can be opened.
The restore time and missing manual steps are recorded for the next test.

Common backup failures

Mistake	What breaks during recovery
Only exporting workflow JSON	Users, projects, settings, retained executions, and complete credential state are not restored as one instance
Database without the original key	Credentials remain encrypted but cannot be used
Copying a live SQLite file casually	The backup may not represent one consistent database state
Skipping binary storage	Execution records may exist while retained documents or images are missing
Restoring straight over production	A bad archive or wrong configuration can remove the working recovery path
Never testing the restore	Missing keys, permissions, node packages, and undocumented steps appear during the incident

Common questions

Where does Docker store self-hosted n8n data?

n8n's standard Docker example mounts a named n8n_data volume at /home/node/.n8n. Your Compose file may use a different volume or bind mount, so inspect the deployment rather than assuming the example name.

Does exporting workflows back up credentials?

Not by itself. n8n provides separate workflow and credential export commands, plus the broader export:entities command. For same-instance disaster recovery, the database, original encryption key, config, and storage remain the stronger complete backup set.

Can I restore into a newer n8n version?

Restore the recorded version first when possible. This separates backup problems from application migrations. After the restored instance passes its checks, read the intervening release notes, take another backup, and perform the upgrade as a separate controlled change.

Sources checked

n8n partner link

Prefer a managed recovery path?

I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Need the recovery path documented?

Send the database type, deployment shape, storage locations, and recovery target. I will help map a backup set and an isolated restore test without exposing production secrets.

Map the restore

Originally published on FloxoLab.

Why I run my home lab like enterprise infrastructure

Sat, 22 Aug 2026 20:19:51 +0000

Originally published on DEV Community in July 2026. This version is updated with the current state of the lab and a new section on what happened when I finally tested my backups.

I'm an IT Systems Administrator / Service Desk Team Lead L2 in Torino, Italy. During the day I manage endpoints and infrastructure for a large public-sector IT provider. At night I run PolarisCore, a home lab built with the same standards I use at work: VLAN segmentation, a real reverse proxy, internal DNS, ZFS storage with redundancy, and monitoring. Not a pile of Docker containers on a single box.

Here's the current state, pulled live via SSH an hour before publishing.

The compute layer — Proxmox

When I wrote the original version of this article, the lab ran on a single Proxmox node with 7.5 GiB of RAM. I had assigned about 10 GiB across the containers. Linux lets you over-commit memory, so it worked until it didn't, and the OOM killer took a container roughly once a month.

A mainboard swap fixed that this week:

pve-manager/9.2.11 (kernel 7.0.14-12-pve)
Host: HP EliteDesk 800 G5, i7-8700T (12 threads)
Uptime: 4 hours (fresh install)
RAM: 12 / 31 GiB used
ZFS rpool (NVMe mirror): 74.3 GB / 236 GB (31%)
Guests: 14 LXC running / 17 total, plus 1 VM

Those containers handle a Caddy reverse proxy, internal DNS (PowerDNS + Pi-hole), a self-built deployment tool, a Next.js search frontend, a job scheduler, an asset inventory, and a handful of smaller services. VLANs separate management, services, IoT, gaming, guest and VPN traffic, with the services VLAN carrying most of what faces the internet.

One detail worth stealing: the node has a single physical NIC. Every VLAN reaches it through one VLAN-aware Linux bridge with 802.1Q tagging, and the switch port is a trunk.

iface nic0 inet manual

auto vmbr0
    bridge-ports nic0
    bridge-vlan-aware yes
    bridge-vids 2-4094

I spent a day convinced I needed a second network card before I checked how the old node was actually wired and found it had been doing exactly this all along. Read your own configs before you buy hardware.

The storage layer — TrueNAS SCALE

TrueNAS 25.10.6
Uptime: 9 hours
Pool DATA (RAIDZ1, 4x8TB): 14.1 TB / 21.8 TB used (64%)
Pool APPS (mirror): 93.8 GB / 460 GB used (20%)
Pool boot: 10.2 GB / 236 GB used (4%)
All pools: ONLINE

22 TB isn't there for the sake of it. It holds a media library (Jellyfin and the *arr stack, running as native TrueNAS apps rather than VMs), project data, and a dedicated encrypted share. RAIDZ1 across four drives gives me a single-drive failure buffer, which for a setup holding real data matters more to me than raw speed.

The part I got wrong: backups

This is the section that wasn't in the original article, and it's the one worth reading.

While preparing the container migration to the new node, I opened the backup storage to confirm I had a rollback path. The most recent archive was dated 19 April. It covered 4 containers out of 14.

For four months I believed I had a safety net. It covered less than a third of the machines and was four months stale. Nothing had alerted me. No email, no red icon in the interface, no failing job. The backup job was configured against an explicit list of container IDs, that list had been written once, and the lab had grown past it. A job that backs up four containers successfully reports success.

So I ran a full backup of everything. It failed on all seventeen guests with the same error:

tar: failed to return to initial working directory: Permission denied

The cause is a two-layer UID translation. Unprivileged LXC containers map their internal users to a host range starting at 100000. The NFS server the backups were written to applies its own remapping on top. The result is a tar process whose working directory becomes unreachable to it partway through, so it can't chdir back when it finishes.

The fix is one flag:

vzdump --all 1 --storage <target> --mode snapshot --tmpdir /var/tmp/vzdump

--tmpdir keeps the working directory on local disk instead of the network share. The archive still lands on the share; only the scratch path moves.

Seventeen archives, then seventeen restores onto the new node. Sixteen of sixteen running containers came back on the first attempt, and the seventeenth was already powered off by design. That was the first time those archives had ever been read by anyone.

The lesson isn't "make backups." Everyone makes backups. The lesson is that a backup job reports on what you told it to do, not on what you needed it to do, and the only way to learn the difference is to restore.

The backup layer — Proxmox Backup Server

The old node didn't get retired. It became the backup target:

Proxmox Backup Server 4.2.5
Host: HP EliteDesk 800 G4, i5-8500T (6 cores), 7.53 GiB RAM
Datastore backup-ct: 40.20 GB / 245.55 GB used (16.37%)
Backup count: 17 CT groups, 1 VM group — 18 snapshots

The first full run finished in ten minutes for eighteen guests. It now runs nightly at 02:30 against every guest, with deduplication, a weekly integrity verification job, and a retention policy that keeps 7 daily, 4 weekly and 6 monthly snapshots.

Three properties make this better than what I had before:

It backs up --all, not a list. A new container is protected the night it's created, with no config change. That single flag is the direct fix for the failure above.
Deduplication is content-addressed at the chunk level. Seventeen Debian containers share most of their filesystem, so they cost far less than seventeen times one container.
Verification is a separate scheduled job. Restoring is still the only real test, but a weekly checksum pass catches silent corruption without me remembering to look.

One thing I have not solved: the backup server sits in the same cabinet as the machine it backs up. That protects me against disk failure and my own mistakes. It does nothing against fire or theft. An off-site copy of the critical subset is the next job on the list, and I'd rather say that out loud than let the diagram imply I'm covered.

The alerting trap, again

I configured email notifications and sent a test. It bounced:

550-5.7.1 Messages missing a valid Message-ID header are not accepted

Gmail doesn't accept mail sent directly from a residential IP address. The fix was routing through an authenticated SMTP relay on port 587 with an app password instead of delivering directly.

Notice the shape of this. If I hadn't sent that test, the only channel that tells me a backup failed would have been silently discarding every message. I would have rebuilt exactly the situation I had just spent a day fixing: a system that looks healthy because nothing is reporting.

Test the alerting path, not only the thing being alerted on.

The network layer

FTTH 10 Gbps from TIM into a UniFi Cloud Gateway Max, distributed over a 2.5 GbE backbone to switches and clients. The 10 Gbps WAN isn't about single-stream throughput to the internet. It's headroom, so the internal backbone never bottlenecks against the uplink when backups, streaming and syncs run in parallel. TLS is a wildcard certificate issued via DNS-01, auto-renewing, with zero inbound ports opened for issuance.

A debugging note from this week that cost me an hour. The new node negotiated its link at 100 Mb/s while everything else ran at 1000 or 2500. My first theory was a bad cable, and I was wrong: the cable was a perfectly good Cat 7. ethtool showed the real answer, that the machine advertised 1000baseT/Full while the link partner advertised only up to 100baseT/Full. Autonegotiation had settled on 100 during one of the many power cycles that day and never retried, because it doesn't. Forcing the speed once and then re-enabling autoneg fixed it, and a small boot service now re-negotiates if it ever finds itself at 100 again.

ethtool <iface> | grep -A2 "Link partner advertised link modes"

That one command separates "the cable is broken" from "the link is stuck", and they have completely different fixes.

The lightweight cloud piece — Oracle Always Free

Not everything lives on-prem. Site analytics run on Umami, self-hosted, replacing GA4 across five sites, on an Oracle Cloud Always Free VM:

Ubuntu 20.04.6 LTS
VM.Standard.A1.Flex — 1 OCPU / 6 GB RAM
RAM used: 694 MiB (11%)
Uptime: 6 weeks
Stack: Umami + Postgres 15 + Caddy, Docker Compose

Six weeks of uptime and it barely registers on CPU. For a low-traffic analytics backend the free tier is more than enough, and there's no reason to pay for a VPS to do this.

A side project that came out of daily frustration

The one piece of software here that isn't infrastructure glue is NovaSCM, an open-source self-hosted alternative to Microsoft SCCM for zero-touch Windows deployment: PXE boot, autounattend generation, network scanning, WiFi 802.1X certificate management, and workflow-based software deployment. It's MIT-licensed, lives on GitHub, and runs as one of the containers above.

Why bother with all this at home

Building it the enterprise way, with segmentation, real certificate automation, redundant storage and a reverse proxy instead of exposed ports, is the best way I know to understand those patterns rather than read about them.

The backup story above is the argument in miniature. I have written backup procedures at work. I have reviewed them. I still had a four-month gap in my own lab, because reviewing a procedure and restoring from it are different activities, and only one of them tells you the truth. When something breaks at 11 pm on my own network, nobody is going to open a ticket about it, and there's no second line to escalate to. That's a different kind of pressure, and it teaches differently.

More on the project and the services I haven't written up yet at polariscore.it.

Simple backups using Rsync with SSH

Thu, 12 Feb 2026 13:35:25 +0000

This post explains how to SSH with Rsync to make backup of your system efficiently and securely.

The only requisite to start here is an access to SSH somewhere.

Create your ssh keys

Here, i just create a keypair called “rsync”, ssh will create a private and a public key.

ssh-keygen -t ed25519 -o -a 100 -f ~/.ssh/rsync

After, just send the public key to the server with scp targeting your server.

 scp ~/.ssh/rsync.pub backup@SERVER

Create a backup script

Create a shell script named rsync-backup.sh with the following content:

#/usr/bin/env sh

set -o errexit

# All variables
SERVER="192.168.1.11"
BACKUP_FILE="/tmp/backup.filter"

# More efficient than playing with --include,--exclude
cat << EOF > "$BACKUP_FILE"
# Include patterns
+ /documents/***
+ /Downloads/***
+ /downloads/***
+ /images/***
+ /musics/***

# Exclude everything else
- /**
EOF

# And finally the rsync command
rsync -avP --delete -e "ssh -i $HOME/.ssh/rsync" \
    --bwlimit=400 \
    --filter="merge $BACKUP_FILE" \
    "$HOME/" "backup@${SERVER}:backups/"

The script here will backup your $HOME with only certain directory in the “include pattern list”. Just ensure the server address is correct.

I also limit the bandwidth because it break my wifi card (bad hardware…)

Execute the script

Just give permission and launch the script.

 chmod u+x rsync-backup.sh
./rsync-backup.sh

Conclusion

Using SSH with Rsync is an efficient and secure method for backing up your system. By generating SSH keys and creating a simple shell script, you can automate the backup process, ensuring that your important files are safely stored on a remote server.

Adjusting settings like bandwidth limitation can help optimize performance, especially on networks with limited resources. This approach not only provides a reliable backup solution but also enhances data security through encrypted connections.

Your WordPress Site Will Fail. Be Ready.

Thu, 18 Dec 2025 14:44:03 +0000

After losing two weeks of work to a crash, I spent years perfecting my
backup strategy. Here's everything I learned managing 10+ client
sites.

Why I'm Writing This

Three years ago, I lost two weeks of work because I trusted backups I never tested. The panic, the scrambling, the realization that my "backup solution" was just an empty promise — I wouldn't wish that on anyone.

Since then, I've done 20+ website restorations, tested every major backup plugin, and built a system that works so well I actually sleep at night. I documented the complete process on my site, but wanted to share it here with the CoderLegion.com community too.

Because if there's one thing I've learned: hope is not a backup strategy.

Website Crashes Are Normal

Updates fail. Plugins conflict. Servers go down. Themes break layouts. Hackers exploit weak spots.

You do not control when this happens. You control how fast you recover.

Most site owners panic. They search logs. They contact hosting. They wait. Hours pass. Sometimes days. Without backups, recovery becomes guesswork.

A backup removes fear. It turns a crash into a routine task. Restore. Check. Move on.

The WordPress Backup Plugin Solution

While there are many backup plugins available, not all are created equal. Some are lightweight and reliable, while others can slow down your site or cause conflicts.

I've tried them all: UpdraftPlus, Backuply, Jetpack, BackWPup, WPvivid, Duplicator, All-in-One WP Migration.

After 20+ website restorations, WPvivid is my choice. It strikes the perfect balance between comprehensive protection and ease of use, without the complexity that makes you need a computer science degree to configure it properly.

What WPvivid Can Do For You

✅ Full website backups
✅ Database-only backups
✅ Files-only backups
✅ Manual backups on demand
✅ Automatic scheduled backups
✅ One-click restore
✅ Website migration
✅ Staging site creation
✅ Remote storage support (Google Drive, Dropbox, Microsoft OneDrive,
Amazon S3, FTP, SFTP)
✅ Backup splitting for large sites
✅ Incremental backups in Pro version

Your First Backup with WPvivid

Here's the critical part most tutorials skip: you need to verify that it works correctly for YOUR specific setup.

Every website is unique — different themes, plugins, hosting environments and configurations. Backups mean nothing if restore fails.

Never trust blindly — test once, then relax.

Step 1: Create Your First Backup

Install and activate WPvivid plugin
Open WPvivid Backup in WordPress, tab "Backup & Restore"
Choose "Database + Files"
Choose "Save to Local"
Click "Backup Now"
Wait for the backup to complete
Reload the page, click "Scan uploaded backup or received backup",
then click "Download"

Congratulations! You have your first backup. But we're not done yet.

Testing the Restore Process (THE MOST IMPORTANT PART)

This is where most people stop. Don't be most people.

Step 2: Test on a Blank WordPress Site

Create a blank test WordPress site (use a subdomain or local
environment)
Install and activate WPvivid plugin on the test site
In the test site, open WPvivid, tab "Backup & Restore"
Scroll down to find the "Upload" section
Click 'Upload' and select the backup file from your local machine
Wait for "The upload has completed" message - click "OK"WPvivid
Restore backup process
Click the "Backups" button (located next to the 'Upload' button)
You should see the uploaded backup - click "Restore" and then
"Restore" again
Click "OK"

Important: Don't close or switch to other tabs during the restore process.

When finished you'll get the message "Restore completed successfully" - click "OK".

Step 3: Verify Everything Works

Reload the page. Go to different pages and sections of your website. Confirm everything is working as expected.

This entire test process takes 5-60 minutes (depending on the size of your site) and is worth every second.

Why Testing Matters (My Hard-Learned Lessons)

I test my backups every couple of months. Here are issues I've caught BEFORE they became disasters:

❌ File corrupted during transfer
❌ PHP timeout during restore
❌ Incompatible plugin files
❌ Invalid backup file format
...and so much more that can go wrong

That's why for every website I have or make, I create a test website to verify the backup works. This practice gives me peace of mind and ensures my clients' websites are always protected and recoverable.

Setting Up Remote Storage (CRITICAL)

I hope you now understand the importance of having your backups NOT in the same place as your website.

Configure Remote Storage:

Go to tab "Remote Storage"
Click on the cloud service you prefer (Google Drive, Dropbox, etc.)
Click "Authenticate" (log in to your account)
Give it a descriptive name so you'll know where to find your backups
later

Automating Your Backups

Now let's set it and forget it:

Schedule Settings:

Go to tab "Schedule"
Tick "Enable backup schedule"
Choose frequency (daily or weekly - I recommend daily for active
sites)
Choose "Database + Files"
Select "Send backups to remote storage" (your authenticated service
will show as active)
6. Most importantly: Click "Save"

General Settings:

Go to tab "Settings" → "General settings"
Set maximum backups retained = 7 (keeps one week of daily backups)
Tick "Merge all the backup files into single package"
Click "Save"

FAQ

How often should I backup my WordPress site?

Most websites: Daily backups
- E-commerce sites: Multiple times per day
- Blogs with infrequent updates: Weekly backups
- The key: Always backup before any major changes

Why should I test my WordPress backups?

Testing backups ensures they actually work when disaster strikes. Many website owners discover their backups are corrupted or incomplete only after they need them.

Is WPvivid free?

Yes! WPvivid has a robust free version that includes full site backups, scheduling, cloud storage integration, and one-click restore. The premium version adds incremental backups, staging sites, and advanced features for $79/year.

The Results: Peace of Mind

Since implementing this system, I've had:

Servers crash
Hard drives fail
Hosting accounts suspended due to billing errors
Security breaches that required immediate rollback
Plugin updates that broke entire sites

Every single time: Restored from backup and was back online within 20 minutes.

My clients never knew there was a problem. My visitors never saw downtime. I never lost sleep or spent hours on emergency support calls.

One Final Rule

If you remember nothing else from this article, remember this:

Every update — every single one — should happen on a test environment first. Not sometimes. Not for "small" updates.

Every. Single. Time.

I learned this the hard way. You don't have to.

Additional Resources

If you want even more details, screenshots, and specific settings, I've documented everything on my site: Complete WordPress Backup Guide

You can also check out my other web development guides:

Nginx: What is It and Why Should You Care?
My Go-To Web Arsenal
Beginner's Guide to Google Search Console

What's your backup horror story? Drop it in the comments. Let's learn from each other's mistakes.