> ## Content Index
> Fetch the complete content index at: https://snubmonkey.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# GHOST CMS: Manually* backup and restore ⏤ Self-hosting.
- URL: https://snubmonkey.com/ghost-cms-manually-backup-and-restore-self-hosting/
- Published: 2025-09-27T00:00:13.000Z
- Updated: 2025-12-09T00:09:20.000Z
- Description: Learn how to back up and restore Ghost CMS manually, including content, configuration, and database. A reliable process ensures your business is safe from crashes, updates gone wrong, or migration issues.
- Author: SNUBmonkeyteam
- Tags: ghost cms, how to 🪄

Ghost CMS is a popular, open-source publishing platform that runs on *Node.js*. While Ghost provides built-in commands and integrations for backup, many administrators prefer manual backups for **full control, portability, and disaster recovery**.

This tutorial covers **step-by-step methods to back up Ghost CMS manually** and then restore it if needed.

## **What To Back Up**

To fully preserve a Ghost installation, you need to back up these components:

1. **Content directory (`/var/lib/ghost/content/` or `content/`)**  
Stores images, themes, logs, uploaded files, and customized `.hbs` files.
2. **Database**
  - SQLite: usually located at `content/data/ghost.db`.
  - MySQL/MariaDB: must be dumped with `mysqldump`.
3. **Configuration files**
  - `config.production.json` (Ghost's main config file in production. It defines site URL, DB, mail, and server settings.)
  - Nginx/Apache reverse proxy configs (optional but recommended).
4. **Custom scripts and SSL certificates** (if stored locally).

## Step 1: Prepare Your Environment

`cd` to your project directory.

```
$ cd /var/www/ghost

```

Stop Ghost to ensure data consistency:

```
$ ghost stop

```

## Step 2: Back Up Content Directory

Copy the entire `content/` folder to your backup location:

```
$ sudo cp -av content /home/backup/ghost/content-$(date +%F)

```

Or use `rsync` for incremental backups:

```
$ sudo rsync -av --progress content/ /home/backup/ghost/content/

```

## Step 3: Back Up Database

### SQLite (default Ghost installation):

```
$ sudo cp -av content/data/ghost.db /home/backup/ghost/ghost-$(date +%F).db

```

### MySQL/MariaDB:

```
$ mysqldump -u ghostuser -p ghostdb --no-tablespaces > /home/backup/ghost/ghostdb-$(date +%F).sql
```

That command is creating a **backup (dump)** of your Ghost MySQL/MariaDB database.  
Let's break it down and explain:

- **`mysqldump`** → tool to export MySQL/MariaDB databases.
- `**-u ghostuser**` → connect as user `ghostuser`.
- **`-p`** → ask for that user's password.
- **`ghostdb`** → the database name (your Ghost database).
- **`--no-tablespaces`** → avoids dumping tablespace info\* (needed on some newer MySQL versions to prevent errors).
- **`>`** → redirect output into a file.
- `/home/backup/ghost/ghostdb-2025-09-26.sql`

### \*What is dumping tablespace info

Great question 👍

In MySQL/MariaDB, a **tablespace** is basically the physical storage file on disk where a table's data lives (often managed by the **InnoDB storage engine**).

When you run `mysqldump`, by default it may try to include **tablespace metadata** (paths, file references) in the dump file.

### Why that's a problem

- If you restore the dump on **another server** or **different MySQL version**, the original tablespace info may not match → leading to errors like:

```
ERROR 3185 (HY000): Can't create/write to file ...

```

- You usually don't need tablespace info for a logical backup (a `.sql` dump). You just need the table definitions + data.

### What `--no-tablespaces` does

- It tells `mysqldump` **not to include any tablespace info**.
- This makes the dump **portable** between servers, versions, and environments.

👉 In short: **`--no-tablespaces` makes your Ghost DB backup safer and more compatible**, since Ghost doesn't rely on custom tablespaces anyway.

######   

## Step 4: Back Up Config Files

```
$ sudo cp -av config.production.json /home/backup/ghost/

```

If you use custom configs (like `nginx.conf`):

```
$ sudo cp -av /etc/nginx/sites-available/ghost /home/backup/ghost/nginx.conf

```

## Step 5: Compress Backup (optional but recommended)

```
$ cd /home/backup/

$ tar -czvf ghost-backup-$(date +%F).tar.gz /home/backup/ghost/

```

## Step 6: Restore Ghost CMS

To restore, reverse the process:

1. **Extract backup archive**

```
$ tar -xzvf ghost-backup-2025-09-26.tar.gz -C /path/to/restore/

```

1. **Restore content**

```
$ sudo rsync -av /path/to/restore/ghost/content/ /var/www/ghost/content/

```

1. **Restore database**
- SQLite:

```
$ sudo cp -av /path/to/restore/ghost/ghost.db /var/www/ghost/content/data/

```

- MySQL/MariaDB:

```
$ mysql -u me -p ghost < ~/path/to/restore/ghostdb-2025-09-26.sql
```

1. **Restore configs**

```
$ sudo cp -av /path/to/restore/ghost/config.production.json /var/www/ghost/

```

If restoring Nginx:

```
$ sudo cp -av /home/restore/ghost/nginx.conf /etc/nginx/sites-available/ghost

$ sudo systemctl reload nginx

```

1. Run doctor

```
$ cd /var/www/ghost

$ ghost doctor

```

  
6\. **Restart Ghost**

```
$ cd /var/www/ghost

$ ghost start

```

## Step 7: Verify Restoration

- Visit your Ghost site in a browser.
- Check logs for errors:

```
$ ghost log

```

- Ensure uploaded images and themes are intact.
- Test database content (posts, tags, users).

Manually backing up Ghost CMS ensures **full control over your blog's safety**. By regularly saving the **content folder, database, and configs**, you can quickly restore from failures or migrate to new servers without relying on third-party tools.

We hope you found these tips helpful and interesting!