You locked HTTPS, tightened
.env, and hardened login. A disk failure or a bad Composer update can still wipe weeks of work.Backups, updates, and patching keep a self-hosted Laravel CMS recoverable. Without a tested restore, security configs only delay the outage.
This guide covers what to back up and how to store copies offsite. It also covers restore drills and a calm patch cadence for Composer, Laravel, PHP, and the OS. Use it after host hardening and auth gates.
It pairs with How to Secure a Self-Hosted Laravel CMS, Harden a Laravel CMS for Production, and Auth, 2FA, and Session Security. For product context, see what Lara Dashboard is.
Why backups and patch cadence matter
Self-hosted means you own the blast radius. A ransomware note, a deleted
storage/ folder, or a migration that corrupts content hits your team first.Patching shrinks the window where known CVEs sit open on PHP, Laravel, nginx, or Composer packages. Backups shrink the cost when something still goes wrong.
Many teams back up the database and forget media. Others update Composer on Friday night with no staging restore. Both habits turn small incidents into long outages.
Aim for a boring rhythm: daily DB dumps, regular media syncs, weekly security review, monthly restore drill. Write the steps so a second person can run them.
What to back up on a Laravel CMS
A CMS is more than the code repo. Treat these layers as separate restore units.
Database
Posts, users, roles, settings, and most CMS state live in MySQL or PostgreSQL. Dump with
mysqldump or pg_dump on a schedule. Prefer consistent dumps (single transaction for InnoDB, or a snapshot-friendly method for busy Postgres).Store the dump compressed. Name files with UTC timestamps. Keep enough history to roll past a silent corruption you notice days later.
Media and storage
Laravel usually keeps uploads under
storage/app (often linked from public/storage). A DB restore without media leaves broken images and empty galleries.If you already store media on S3 or Cloudflare R2, version or sync that bucket. If media is local, rsync or snapshot it off the box. Watch for symlinks: backing up the link path instead of the real files is a classic miss.
Secrets and env (offline only)
Copy of
.env belongs in an encrypted vault or password manager, not in the same S3 prefix as public dumps. Never commit .env to git.Document which keys rotate after a restore (APP_KEY, DB password, mail, object storage). Restoring an old
.env onto a new host without updating DNS and credentials creates new failures.Custom code and modules
Your application code should already live in git with a committed
composer.lock. That is your primary code backup. Tag releases you deploy to production.Capture custom modules, themes, and one-off scripts that never made it into the repo. Check
Modules/, local packages, and deploy hooks.Cron, queue, and scheduler config
Export crontab entries, systemd unit files, Supervisor or Horizon configs, and queue connection settings. A restored app that never runs
schedule:run looks healthy until scheduled jobs silently stop.Note which queues process media, mail, and webhooks. Restore order matters: DB and storage first, then workers.
Backup strategies that hold up
Database dumps
Nightly full dumps work for many CMS sizes. Add more frequent dumps if editors publish all day. For MySQL,
mysqldump --single-transaction --routines --triggers is a common baseline. For Postgres, pg_dump -Fc gives a flexible custom format.Pipe dumps through gzip or zstd. Upload to offsite storage right after the dump finishes. Delete local copies after a successful upload if disk is tight, but keep a short local cache for fast restores.
Filesystem and snapshots
Provider snapshots (DigitalOcean, Linode, AWS EBS, Hetzner) capture the whole disk fast. Use them as a second layer, not the only layer. Snapshots on the same account can vanish with the account.
For media trees, rsync or rclone to object storage on a cadence. Incremental syncs keep large libraries manageable. Exclude cache and compiled views; those rebuild.
Offsite retention and encryption
Keep copies in a different account or provider when you can. Apply a retention policy: for example daily for 14 days, weekly for 8 weeks, monthly for 6 months. Match retention to how long bad edits can stay unnoticed.
Encrypt archives at rest (age, gpg, or bucket SSE with keys you control). Restrict who can download production dumps. A public backup bucket is a data breach with a schedule.
Media pitfalls
Large
storage/ trees fill disks mid-backup. Monitor free space and fail loudly. Follow symlinks intentionally; decide whether to dereference them. Do not back up node_modules or vendor from production if you rebuild from lockfiles on deploy.If editors upload huge videos, consider object storage early so the app disk stays small and backups stay predictable.
Test restores and rollback drills
An untested backup is a hope file. Schedule a monthly restore to staging.
Pick a recent dump and media snapshot. Restore into a staging database. Point a staging app at that DB and storage. Log in, open a few posts, confirm featured images load, and run a smoke test on forms or admin actions you care about.
Time the restore. Write down RTO (how long until the site works again) and RPO (how much data you can afford to lose). If a full restore takes four hours, plan maintenance windows and communications around that fact.
Practice rollback after a bad deploy the same way: keep the previous release artifact, previous lockfile, and a DB dump taken before migrations. Migrations that drop columns need extra care; sometimes you restore DB first, then code.
Document who runs the drill, where credentials live, and how to declare success. Rotate the person who runs it so knowledge is not stuck in one laptop.
Composer update hygiene
Composer is how most Laravel CMS dependencies arrive. Treat updates as controlled releases, not Friday improvisation.
Run
composer outdated on a schedule. Prefer composer audit (or your CI equivalent) so known advisories surface early. Read changelogs for major bumps before you merge them.Always commit
composer.lock. Deploy with composer install --no-dev --optimize-autoloader (or your platform's equivalent) so production matches the lockfile you tested.Update on staging first. Run migrations there. Click through admin, publish a draft, upload a small file. Only then promote to production during a planned window.
Security releases for Laravel and popular packages deserve faster paths. Still use staging when you can. If you must hot-patch production, take a DB dump and note the previous lockfile hash first.
Framework, PHP, and OS patching
Keep Laravel on a supported minor line. Watch the Laravel security advisories and framework release notes. Jump major versions on a project plan, not as a side effect of one package update.
Patch PHP with your OS packages or the PHP build you use in containers. Match the PHP version your
composer.json platform constraints expect. After a PHP bump, rerun Composer and your test suite.Patch the OS regularly: kernel, OpenSSL, nginx or Caddy, MariaDB/Postgres clients and servers. Unattended upgrades help for security packages if you accept occasional service restarts and monitor them.
Use Laravel maintenance mode (
php artisan down / up) when you need a brief freeze for migrations or risky deploys. Share a secret bypass for operators. Tell editors when the window starts and ends.Zero downtime vs brief maintenance windows
True zero downtime needs careful deploy tooling: symlink releases, shared storage, queue workers that drain, and migrations that stay backward compatible across two app versions.
Many small CMS installs do fine with a five to fifteen minute maintenance window. Honesty beats a half-broken "zero downtime" deploy that serves mixed code and schema.
Choose based on traffic and risk. Public marketing sites may tolerate a short banner. Heavy editorial mornings may prefer late-night windows. Record the choice in the runbook.
Monitoring: failed backups and disk space
A backup cron that fails quietly is worse than no cron. Alert when the dump job exits non-zero, when the upload to S3/R2 fails, or when the newest backup is older than your RPO.
Watch disk space on the app server and on the backup volume. Full disks stop dumps mid-file. Watch inode counts on media-heavy hosts too.
Log Composer audit results in CI. Fail the pipeline on high-severity advisories you have not waived. Pair that with uptime checks so a failed deploy is visible fast.
Weekly and monthly checklist
Use this as a living checklist. Assign an owner. Tick boxes in the runbook, not only in your head.
Daily: DB dump uploaded offsite; backup age within RPO.
Weekly: Media sync verified; composer outdated/audit reviewed; OS/PHP security updates on staging; disk/inode free space.
Monthly: Timed restore drill to staging; retention cleanup; encryption keys reachable; rollback path documented.
As needed: Security releases staged then promoted.
Weekly: Media sync verified; composer outdated/audit reviewed; OS/PHP security updates on staging; disk/inode free space.
Monthly: Timed restore drill to staging; retention cleanup; encryption keys reachable; rollback path documented.
As needed: Security releases staged then promoted.
Print it next to the HTTPS and auth checklists from the earlier security posts.
Common failure cases
DB only, no media. Restore looks fine until every featured image 404s. Always pair dumps with storage.
Backups on the same disk. When the disk dies, the dumps die with it. Offsite is not optional.
composer update on production. Lockfile drift and surprise major upgrades follow. Update on a branch, test, then deploy install from lock.
Never restored. Permissions, paths, and missing extensions show up only during a real incident. Drill monthly.
Silent cron failure. Mail or chat when the job fails. Check the last successful artifact age every week.
Where LaraDashboard fits
Disclosure: LaraDashboard is our open-source Laravel admin and CMS. We recommend it when you want a self-hosted CMS you own, with content, media, and roles in one Laravel-native back office.
You still control backups and updates. That is the point versus plugin roulette on a shared host you cannot snapshot cleanly. Standard Laravel deploy and dump tools apply. You are not waiting on dozens of third-party plugins to ship patches before you can sleep.
LaraDashboard does not replace your offsite bucket, restore drills, or Composer discipline. It gives you a codebase and admin you can version, dump, and patch on your schedule. For roles after restore, keep the RBAC guide handy. For host gates, keep the production hardening checklist open.
FAQ
How often should I back up a Laravel CMS database?
Daily is a solid default for most editorial sites. Increase frequency if you publish all day and cannot lose hours of work. Match the schedule to your RPO.
Is a cloud provider snapshot enough?
Use snapshots as a second layer. Also keep logical DB dumps and media copies offsite. Snapshots alone do not always give clean point-in-time app restores.
Should I run composer update on the live server?
No. Update on a branch or staging, commit the lockfile, test, then deploy with
composer install from that lockfile.What belongs in a monthly restore drill?
Restore DB and media to staging, boot the app, verify login and content, time the process, and note gaps in the runbook.
How do I handle .env in backups?
Store it encrypted offline or in a secrets manager. Do not drop plaintext
.env next to public dump files. Rotate credentials after a suspected leak.Do I need zero downtime deploys?
Only if traffic and SLAs demand it. A short, announced maintenance window with
artisan down is often safer than a complex partial rollout.Where does LaraDashboard change this picture?
You run a Laravel app you control. Backups and patches follow normal Laravel ops instead of chasing many unrelated plugin update channels. You still must schedule dumps and drills.
Ending note
Backups, updates, and patching close the recoverability gate on a self-hosted Laravel CMS. Dump the database, sync media offsite, encrypt archives, and prove restores on a calendar. Patch Composer, Laravel, PHP, and the OS through staging when you can.
Auth and HTTPS without a tested backup still leave you one bad disk away from a rewrite. Keep the weekly checklist next to your security runbook.
If you want a Laravel-native CMS you can dump, version, and patch on your own terms, try the LaraDashboard demo or read the docs on the site. Pair this guide with the self-hosted security pillar, production hardening, and auth posts. Keep the next deploy behind a clear backup and patch bar.
