Backing up the files of a Drupal site

A Drupal site has two halves: the files and the database. This article is about the files. The other half is in backing up the database of a Drupal site, and the two have to be taken at the same moment or neither is worth much.

Which files are genuinely irreplaceable

Drupal core and public modules can be downloaded again any time. What cannot is this:

Where it lives Why it matters
sites/default/files Everything your users uploaded: images, PDFs, attachments. None of it is in the database and none of it can be fetched from anywhere. This is the most important directory on the site.
sites/default/settings.php The database credentials and the site keys. Without this file Drupal does not start.
Themes and modules written for you If anyone wrote code for this site, it is under themes or modules, and it exists nowhere else.
Exported configuration If the project uses configuration export, that directory is half the build work.
The .htaccess at the root Redirects, access rules and the https enforcement live there, and go missing quietly.
The uploaded files directory is the one people forget. A backup that takes the database but not sites/default/files restores a complete site with every image broken. Working out why takes a while, and fixing it takes longer.

Four ways, from the most automatic to the most manual

Way When it is the right one
Our daily backup It runs whether or not you think about it, and you restore from the panel. It is the safety net: see how long we keep backups.
JetBackup in cPanel Lets you choose the day and what to bring back: home directory, individual folders, or the whole account. See restoring with JetBackup.
The Softaculous backup If Drupal was installed there, the installations list has a button that stores files and database together, at the same instant. It is the most practical of the four precisely because it catches both halves.
Your own copy, off the server The only one that still exists if the account does not. This is the one that matters before a big change.

Taking your own copy, step by step

1 In cPanel, open File Manager and navigate to the directory where Drupal lives.
2 Put the site into maintenance mode before you copy, if it is taking visitors. A copy snatched mid-upload contains half a file.
3 Select the installation directory and use Compress to pack it into a zip or tar.gz.
4 Download that archive to your computer and keep it somewhere other than the server: an external disk, a cloud folder, whatever you prefer.
5 Delete the archive from the server. Left behind, it doubles your disk usage, and if it sits inside the public directory anyone who guesses the name downloads your entire site.
6 Open the archive on your computer and check that sites/default/files is in there with content. A backup nobody has ever opened is not a backup.
If you prefer FTP, the same job works with FileZilla: see FTP accounts and FileZilla. Downloading thousands of small files is slower than compressing first, but it does not use server space.
Compressing a large Drupal costs processes and memory. On a shared account a very large compression can be cut short and leave an incomplete archive. If that happens, compress in parts, or use JetBackup, which was built for this. On the account file ceiling, see the limits of your account.

About to make a big change and want to be sure you can get back? Tell us beforehand and we will check it with you.

Open a support ticket

SEE ALSO

Hosting plans and what each one includes

Support Policy

Frequently asked questions

RECOMMENDED PRODUCT

Web hosting with cPanel

Domain and SSL included, daily backups and the panel you already know. from $6.60/mo (3-year plan, with coupon)

See plans
  • 0 Users Found This Useful
Was this answer helpful?