Backup best practices

There are plenty of results, blogs, tutorials when you google “Ghost CMS backups”, but is there a best practice the folks at Ghost about how to do this?

I.e. What directories should be backed up, which database tables/data etc?

I would like to set something up using cron and have it dumped to an S3 bucket, but would like to know what should actually be backed up to avoid data loss should I need to restore or migrate everything to a new EC2 instance.

Any help appreciated.


Hi @omisnomis :wave: The best way to have all the content backed up at the moment, is doing an export:

This ensures you have all the information stored in db ready to be restored on current or new Ghost instance.

Then, there are 2 other parts that need to be backed up manually:

  1. The /content/images folder (or the place you have configured to store images and other assets)
  2. The theme

Additionally, if you are using custom routes.yaml for dynamic routing or redirects.json for custom redirects, they should be backed up separately as well.

These components should be enough to fully restore a new instance :+1: Let me know if you need any more information :wink:


Hey @naz - thanks for responding :slightly_smiling_face:

The exporting etc is all quite manual. I assume all the export does is query the database and does a dump of the data?

When I do show table on ghost_prod I see 31 tables - are they all needed? I assume only a small selection would be needed and I could create a regular scheduled dump of them, zip it up and have it stored in a secure S3 bucket to avoid having to manually do an export through the admin interface?

1 Like

The export can be also done through experimental /db endpoints in Admin API if you are looking for automation (note experimental would mean you’d need to keep an eye on any upcoming changes).

Most of the tables are needed but some are excluded for security reasons. In theory, if you are ok creating a dump of the whole database and are sure the data will be stored securely, then there’s no one to stop you :smile:

Thanks for replying again :slight_smile:

Is there any documentation for the /db endpoint? I couldn’t find it in the (API)[] docs - but that could well be because it’s experimental at the moment.

Thanks for the list of the excluded tables. I wasn’t sure if I could cause issues further down the line, by exporting certain tables, and then trying to reimport them should I need to restore everything.

But it sounds like I could safely do a SQL dump and restore it into a fresh database at a later date, should my server ever need to be destroyed/restored?

I’m watching this Topic also very closely because I think this Backup thingy is missing in Ghost as a proper in-house Solution to it.

Is there any Chance to get this Function as a Add-on/Plugin in the further Development of Ghost?
I mean this in maybe the same kinda Way how it works for WordPress, but without having to deal with multiple different Plugins for this and don’t know how secure they are.

I provided an option for automating Ghost backups by using linux scripts here:

There are others, of course (if you search on Google you will find a few python scripts as well).


Thanks @dsecareanu - I may just reference some of that when I’ve heard back from @naz :+1:

1 Like

Yes, if you plan to restore on the same domain/server it’s perfectly fine approach :slight_smile:

Is there any documentation for the /db endpoint?

It is undocumented for exact reason you mentioned - it’s still experimental :wink:

I’m being pedantic, I just want to make sure I’m not screwing myself over. So if I started creating SQL backups, and at some point, in the future my server gets corrupted and it had to be shut down.

I could then create a brand new server, with a fresh install of Ghost, and just import my data and it should work just as before the corruption?

I wouldn’t somehow overwrite some critical data, or a checksum of installation, and cause a catastrophic failure of the Ghost system?

Of course, this comes with all the usual caveats - I’m using the open-source version so you wouldn’t support it, different versions could have incompatibility issues etc. Just from a ‘theory’ point of view - this should all be fine?

I thought that might have been the case :smile:

P.S. I really appreciate all the replies. Considering I’m not a Pro customer, you guys are really helpful and responsive!

Those thanks extend to @naz, @Kate and @Kevin specifically - you’ve all replied to my questions directly (sometimes stupid questions!) as well as the whole team that support the Open Source community.


If you have an SQL dump, a copy of your /content/ directory, and your config.production.json then you’re all good. The config file is not strictly necessary if you know the values because you can recreate fairly easily but it’s useful to have to hand :slight_smile: (you would likely need to update the mysql auth details inside it unless you’ve reused passwords :scream_cat:)

I wouldn’t somehow overwrite some critical data, or a checksum of installation, and cause a catastrophic failure of the Ghost system?

There’s no checksum like that in Ghost.


Perfect - thanks @Kevin! I didn’t actually intend to tag you to get you involved (obviously happy you did though), I just wanted to extend my thanks specifically to the three of you for helping me out so far.

I think I’ve got all the information I need now - I’m going to make a Go CLI tool to automate these steps.

Happy to share when it’s done!

1 Like

In theory, I think, all CMS’s or even custom made sites should work if you move the identical files, database and configs to another server. The same is valid for entire servers (i.e. server images). So this is nothing necessarily related to Ghost unless there was some unique ID or something generated at install time that wouldn’t allow you to match two different installations (but I don’t think any open source project would over complicate itself in such a way).

Yeah - in theory :slight_smile:

It was worth checking though - assumptions are never a good idea.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.