My Approach To Backing Up My Online Writing

I have written a lot about backups in recent months . So much so that I reckon that there is probably an entire book’s worth of material about how to back up everything from Linux computers to web hosting accounts to NAS servers buried somewhere in this Medium account.

How To Back Up Your Linux Computer to a Synology NAS

What I worry about backing up most of all, though, is my writing. All of it. No matter where it appears, it represents a record of my thinking on things that matter to me. I invest time and energy into it. Some of it is good. Some of it is terrible (yes, I’m aware). But I want to keep essentially all of it for posterity.

The 3–2–1 Approach To Backups

The 3–2–1 approach to backups — which may as well become my tagline these days — is as follows:

You start with the source of data that you want to back up.

You want to take — at least — two backup copies of that. Two plus the original one equals three.

You want to make sure that those two copies are not on the same storage media. And that neither of them are on the same storage medium as the original data source. We’re talking physical hardware here. Ideally separate computers so that if an entire device gets fried in a power surge the onsite backup lives. If not, then at least different drives on the same computer (keeping an onsite backup on an NAS or a plug in USB SSD is fine too).

Finally you want to make sure that one of the backup copies lives offsite. That means somewhere that isn’t the same place — physically — as backup one. This is designed to ensure so that if the place where the primary and onsite backup live gets flooded, for instance, we’ll still have a copy.

Here’s how we can apply that when it comes to backing up our writing.

A Real Example

When I click on the ‘publish’ button, this post will take up residency on Medium.com.

Technically, the post ‘content’ will be written to a database. The images, as soon as I upload them, will be stored in Medium’s CDN.

But if Medium were to catastrophically lose all of its users’ data my writing would vanish. (Let’s put to one side the fact that a website of Medium’s size vanishing overnight is prodigiously, infinitesimally unlikely..)

If you write for websites then the URLs breaking or the site going offline are much more likely scenarios.

We need two backups. And one of them has to be stored onsite.

The first thing I do, whenever I post something that appears on an external site like Medium, is to replicate the post — with the appropriate canonical link — on either my blog or a separate Wordpress piece that I keep just for backup purposes to house an archive of my writing.

This is a simple Wordpress site. It’s ugly. It’s for my own purposes. But — from a backup perspective — it provides me with a convenient place to keep an archive copy.

I explain how I built this very simple archive in the video embedded above.

But essentially the procedure was as follows.

I used the Wordpress Advanced Fields plugin to create entities called ‘backup copy’ for every post that I replicate there. And another one called ‘originalurl’ which replaces the default Wordpress article permalink ’ with the live URL where the article is published.

Advanced Custom Fields

I then baked these into a child theme which I created as follows:

<div class=”post-byline”>
 <span class=”post-date”>
 <?php
 $date = get_the_date();
 printf( esc_html_x( ‘Published %s’, ‘Published DATE’, ‘chosen’ ), $date );
 ?>
 </span><br/>
 IN <?php the_field(‘pubtitle’); ?>
 <br/>
 <a href=”<?php the_field(‘publishurl’); ?>” target=”_blank”>ORIGINAL LINK &nbsp;&nbsp;|&nbsp;&nbsp; <a href=”<?php the_field(‘backupcopy’); ?>”target=”_blank”>LOCAL BACKUP</a> </a>
 
</div>

Now, whenever I post a piece on an external website, I will take a full page rolling screenshot and save that as a PDF.

I then input these fields into the Wordpress post as follows:

I added another local copy field which isn’t linked to in the theme and gave this field the title ‘hiddenbackup’. The purpose of this is so that I have somewhere to upload an article if the backup copy shouldn’t be publicly exposed (example: I recently wrote an article for a magazine that is behind a paywall.)

Just make sure that when you set up the custom field for your writing as a PDF that you tell the plugin to return the file URL when it is called in your theme.

To make the process easier I also recommend that you limit the selection library to just the media updated to that particular post:

Remember that when you’re creating with Wordpress:

• Posts are saved in the MySQL database. If you forget what your database’s name is, then have a look in your wp-config.php.
• Things like PDF attachments are stored in the filesystem. That’s the Wordpress root.

Once a day, I pull down a backup of this backup archive using rsync.

The methodology is similar to what I described here:

How To Back Up Shared Hosting Onto A Linux Host

The NAS which I back up to then replicates that up to a second cloud repository.

That leaves me with the original piece of writing backed up to two clouds (my hosting plus the cloud backup repository) and my local host.

It also means that — within the bounds of reasonable probability — whatever I write is safely copied.

Summary

• You can back up your writing as soon as it has been published or do so in batches (although the latter is obviously risky).
• 3–2–1: Everything you write, hosted online, needs to be backed up locally and to another cloud.
• You can use Advanced Custom Fields to create a Wordpress “blog” that you actually just use for backing up your online clips. You just need to make sure that you have a way to back up this website frequently. Alternatively, you could use a free online blogging platform that has a good back up functionality.
• Don’t forget to push the backup up to a cloud so that you have an offsite copy independent of your primary piece of writing.