how do i back up my website? the checklist that survives a crash, a hack and a mistake
web · Oct 7, 2026 · 5 min read
backups are the seatbelt of websites: everyone agrees they matter, almost nobody checks theirs works. so instead of a ritual, here are the three questions that turn "i think my host does backups" into an actual answer.
the three questions
1. what would i actually lose, right now, if the site vanished?
for most small sites the answer splits in two: the files (pages, images, code, theme) and, if the site has dynamic parts, the database (form submissions, posts, orders, bookings). a backup that copies files but not the database restored a beautiful site with an empty guestbook. know which half your site has. a purely static site — pages and images only — is the easy case, and what is hosting touches why that simplicity also makes moving hosts trivial.
2. where do the copies live?
this is the question that exposes most "backups". the copy that lives on the same server as the site is not a backup — it is a twin. the ransomware that encrypts the site encrypts the folder next to it; the hosting bill that lapses takes both down together; the delete-everything click does not ask which one you meant. a real backup lives somewhere the site's own disaster cannot reach: another account, another provider, your own drive.
- host snapshots: useful for instant rollback after a bad update. keep them, but count them as the first copy, not the last.
- a manual export you download monthly: the actual safety net for content and database.
- automated offsite backups: worth 2-5 euro a month if the site earns money while it sleeps.
3. has a restore ever been tested?
a backup that has never been restored is not a backup, it is a hypothesis. the only test that means anything: pick a quiet evening, restore the site to a scratch address, click through it. if you have never done this, schedule it once — it takes an evening and it either works, or you learn now instead of during an outage.
how often, by site type
- brochure site that changes twice a year: backup when it changes. an unchanging site backed up daily is a comforting waste.
- blog with weekly posts: weekly files plus database, or after every publishing session.
- shop or anything taking money or bookings: daily, automated, offsite, and a restore test twice a year. on a shop the database is the business.
the frequency rule in one line: back up as often as you would hate to re-do. if losing a week of changes is fine, weekly is fine. if losing one day of orders is not, daily is not negotiable.
and when it is already too late
if you are reading this because the site is currently broken or defaced, the order changes: do not poke at it, capture what you can, and follow the aftermath steps in my site was hacked what do i do now — where, spoiler, the first question you will be asked is exactly the one this post answers.
one last thing worth saying to the "it will not happen to me" voice: the overwhelming majority of site losses are not dramatic hacks. they are failed updates, expired cards, cancelled cards, wrong clicks and hosts going under. boring, and completely survivable with a copy off to the side.
FAQ: the questions i actually get
does my host already back up my site?
most reputable ones take snapshots — ask how many days they keep, whether the database is included, and what a restore costs. their answer is a floor, not a plan: the offsite copy is still yours to own.
is a plugin backup good enough?
the tool is fine; the destination is what matters. a plugin that stores backups on the same server has made a twin, not a backup. point it at cloud storage or downloads.
what about my shopify/wix site?
platforms run their own redundancy, but your content is theirs to snapshot, not yours to download. export products and content periodically anyway — it is also your exit ticket if you ever leave, which how do i make a website explains the economics of.