There are a lot of schemes out there to backup your ghost blog. Most of which involve archiving your blog at a regular time interval and then pushing it to a backup server, etc but the scheme that I am going to present in this blog post is going to the smoothest of them all. Not only it is going to be the simplest in terms of backing up and then restoring your ghost blog but it also is going to be the only one that would back up your blog in real time.
Please be informed that to comprehend this blog post a working knowledge of Docker is required. Also, irrespective of the simplicity of the solution proposed here it is going to be of utter most importance to understand the scheme properly before implementing it so as to avoid screwing your backup. With that said, let's begin!
The solution that I am proposing here backs up your ghost blog on your Dropbox account. Plus it makes use of the whitelisting based selective sync scheme in Dropbox that I recently crafted besides requiring the ghost blog itself to be hosted as a Docker container.
The solution makes use of Docker Volumes to isolate the ghost blog data that needs to be backed up, the
content directory, in particular. This allows backing up the relevant data only and not the complete ghost installation to Dropbox. As depicted in the diagram below, the named docker volume,
content-myblog is attached to both the dropbox and ghost containers at
/var/lib/ghost/content directories, respectively. Owing to which the data that needs to be backed up is made available to both the dropbox and ghost containers. The directory locations where the named volume is attached is of significance because for ghost container
/var/lib/ghost/content is the directory where ghost looks and stores it's data while for dropbox container
/dbox/Dropbox/ghost/myblog/content is the directory which it syncs to the Dropbox server.
This ghost data once made available to dropbox docker container is then whitelisting based selective sync to your Dropbox account. Whitelisting allows only data in the named volume to be synced i.e., the rest of your Dropbox data is blacklisted and isn't synced locally. This saves both bandwidth and storage. Plus allows you to use your existing Dropbox account. I have already explained this selective sync strategy in a recent blog post which you can read here.
Setting up the architecture explained above is achieve via Docker-Compose. You can have a look at this sample project on github. The README available on this repository would guide you on how to bring up this architecture.
As already mentioned that this scheme is a real time backup scheme i.e., there are no time based snapshots of your blog data. Therefore it is of utmost importance that the order in which the containers are brought up is correct. An incorrect order would result in corruption of the backup. It is for this particular reason that I have written two different docker-compose yml files. Making it explicit that it is dropbox container that needs to be brought up first. Next, the host should be registered to your Dropbox account, subsequently, allowing the backup to be synced locally completely. It is then that the ghost container should be brought up. This strategy is necessary owning to the fact that when a volume is attached to a container at a directory location, the content of that location is overwritten by the content in the volume. But in cases where volume is empty that data is written other way round. When you bring up a fresh ghost container, it's
content directory is already populated with basic content to kick start your blog. If the named volume is attached first to this container, the volume would be written with all this new content. And if you already have a backup of your ghost blog that you wish to restore, attaching this volume to dropbox container now would results in sync conflict leading to corruption of backup. Bringing up a fresh ghost blog without any backup to restore wouldn't result in any issue.
One last point that needs attention here is that if you wish to bring up multiple ghost blogs on the same machine, you would need to attach same number of docker volumes per blog to the dropbox container.
Go ahead. Try it for yourself! For an encouragement, this blog is backed up with this very scheme.