Guide Backups & Recovery

How to back up your website

Files and database, taken together, kept somewhere other than the account they protect — here are three ways to manage both.

iFastHosting Support Team Updated 26 August 2026 8 min read Beginner

A website is not one thing. It is a folder of files sitting on a server, and a database sitting next to it, and the two only make a working site when they are both present and pointed at each other. Back up one and not the other, and what you have saved is not a backup — it is half of one.

This guide covers backing up any website: a static site, a custom application, or a CMS. If you run WordPress specifically, our WordPress backup guide covers the same ground with WordPress-specific detail on wp-content and wp-config.php.

What a backup actually has to contain

Part	What it holds	Where it lives
Files	Your application code, images, uploads, stylesheets, and configuration files such as `.htaccess`	The web root of your hosting account
Database	Content, users, settings, and — for a shop — every order and customer record	MySQL, running separately from the files

If your site is entirely static HTML with no database, the files are the whole backup. Almost everything else — WordPress, most other content management systems, any custom application with user accounts or a shop — needs both halves, taken at roughly the same time, so a page referenced in the database still exists as a file and vice versa.

Method 1: your hosting control panel

The fastest route, and the one to reach for before any change you are nervous about. The backups section of your control panel can take a snapshot of the whole account — files and databases together — in one action, without you needing to know which folders or database names matter. Because it runs on the server rather than over your own connection, it copes with large sites without timing out.

Take one manually, don't just rely on a schedule

An automatic nightly backup protects you from disaster. A backup taken sixty seconds before you install a plugin, run an update, or edit a config file protects you from the far more common case: a change that goes wrong immediately, where you want to be back to exactly where you started, not to a snapshot from last night.

Method 2: by hand, with FTP and mysqldump

Worth doing at least once so you understand what the control panel is automating for you, and useful when a site is too large or too broken for an automated tool to finish cleanly.

The files

Connect over FTP or SFTP and download your web root. Make sure hidden files are visible in your client first, or you will miss .htaccess and any dotfiles your application relies on. For a large site, compress it on the server first if you have shell access:

tar -czvf backup.tar.gz public_html/

That produces a single compressed archive you can download in one transfer instead of thousands of small ones, which is both faster and far less likely to fail partway through.

The database

In phpMyAdmin, select the correct database and use Export with the Quick option in SQL format. That downloads a single .sql file containing every table, every row, and the structure needed to rebuild it.

Over SSH, the same job is one command, and it handles far larger databases without a browser timeout in the way:

mysqldump -u username -p database_name > backup.sql

You will be prompted for the password rather than typing it on the command line, which keeps it out of your shell history. If you are not sure which database a site uses, most applications state it in a configuration file near the site root.

Method 3: automate it

Doing this by hand once is educational. Doing it by hand every week is how backups stop happening. A schedule — through your control panel, a plugin, or a cron job running the commands above — removes the human factor. Automating your backups covers the options and what to check once a schedule is running.

Get a copy off the account

A backup stored only on the account it protects shares that account's fate. If the account is suspended, compromised, or the disk itself fails, a backup sitting in the same place is not a separate copy — it is the same risk twice. Download backups periodically, or point an automated job at storage you control elsewhere. Where to keep your backups and the 3-2-1 rule both go into this in more detail — the short version is three copies, on two different kinds of storage, with at least one of them off-site.

The step almost everyone skips

An untested backup is a belief, not a safeguard. Archives stop partway through, database exports get truncated by a timeout, and a schedule can fail silently for months while you assume you are covered. None of that is visible until the day you actually need the file.

Restore your backup to a subdomain, a staging copy, or a local environment, and load the site. It takes a short amount of time and turns an assumption into a fact. How to test that a backup works walks through what to check.

A routine worth keeping

Scheduled backups matched to how often the site actually changes.
A manual backup immediately before any update, migration, or risky edit.
At least one copy stored away from the hosting account itself.
A restore test when the routine is first set up, and again whenever you change host, plugin, or provider.

Every plan here includes a 30-day money-back guarantee and free migration, and support can help if a restore goes wrong — but the copy you keep somewhere else is the one that is always, unconditionally, yours. If you would like a hand setting a backup schedule up, contact us and we can talk through the options for your plan.