Keep your own copy of the site away from your host, keep older copies for a year or more, and take one before every move. A backup you have never restored is only a hope.

Twelve years, lost in a move

A social site that was among the biggest on the web a decade ago has confirmed that music, photos and videos uploaded over roughly twelve years were lost during a server migration.

Users had been finding gaps for some time. The scale of it was widely reported this week.

It is a large company and an unusual scale. The mechanism is not unusual at all.

Files go missing in moves, the loss is noticed late, and by then the copies that could have saved them have rotated away or never included them.

What goes missing in a move

The first is the one that catches small business sites. On a WordPress site, every uploaded image and document usually sits in a folder sorted by year and month, separate from the database that holds the pages.

A move that copies the database and only part of that folder leaves pages pointing at files that are not there.

Why the loss is noticed late

A missing file on a page nobody visits produces no error that anyone sees.

The new home page looks perfect, because somebody checked it. The gallery from 2013, the price list linked from an old blog post, the photographs of a finished project: nobody checks those.

Months pass. A customer asks for something old, or someone finally scrolls back through the archive, and the gaps appear.

By then the old hosting account is closed, and every copy made since the move is a faithful copy of a site that was already missing those files.

Your host's backups are not your backups

Many hosting plans include backups, and many owners assume that settles it.

A host's backups exist mainly to restore its own servers after a failure. They are often kept for a short window, days or a few weeks, and older copies are overwritten.

They sit with the same company, sometimes in the same data centre as the site. If the account is suspended over a billing dispute, or closed when you move away, its backups usually go with it.

And when a host moves its own servers, its backups may share whatever went wrong.

Your own copy, somewhere else

Your own backup is one the business can reach without the host's help.

It lives with a different company, in an account the business controls, with more than one person able to get in. It includes the files, the database and anything else needed to rebuild the site.

Whoever maintains the site can set it to run automatically and check that it does. It is routine site care, not an exotic extra.

Keep the original photographs and documents as well, in the business's own storage. A website is a publishing copy, not an archive.

Old copies, not just recent ones

Losses in a move are often found months later. A scheme that keeps the last seven days protects you from last night's mistake, not from a file that went missing in October.

Keep a daily copy for a week or two, a weekly copy for a couple of months, and a monthly copy for at least a year.

And before any move, redesign or change of platform, take a full copy and set it aside untouched. Keep it for at least a year after the move.

A worked example

A wedding photographer moved her website to a new host in the spring of last year. The developer copied the site, checked the home page and the latest galleries, and closed the old account a month later.

In February, a couple married in 2013 asked for a link to their gallery to order an anniversary print. The page loaded with empty frames where the photographs should have been.

The transfer of the uploads folder had begun with the newest years and stopped partway; every year before 2015 had never arrived. The new host's backups all dated from after the move, so every copy lacked the same files.

The photographer had the originals on her own archive drives, and rebuilt the old galleries over several weeks of evenings.

The site now has its own backup at a separate company, monthly copies kept for two years, and a rule that any move ends with a file count on both servers.

Checking after a move

The cheapest protection is a check the day after any move, while the old account still exists.

Compare the number of files in the uploads folder on the old server and the new one, and compare the size of the database. Any difference needs explaining before anything is closed.

Then open a sample of the oldest pages on the site, not the newest: the first blog posts, the earliest galleries, documents linked from pages nobody has edited in years.

A tool that crawls the site for broken links and missing images will find what a person browsing would miss.

A copy you have never restored

A copy you have never restored is a hope, not a safeguard.

Backups fail quietly. A job stops running after a software change, an archive is missing the database, or nobody knows the password to the account where the copies live.

The only proof is to restore one to a test copy of the site and look at the result. That belongs on a schedule, not on the day you need it.

The counter-case

Some sites need far less than this.

A five-page site with no gallery and no blog, rebuilt from scratch every few years, has little that can quietly disappear, and a modest backup covers it.

Some hosting arrangements include proper off-site backups with long retention, run by people who test them. If yours does, confirm it in writing and know how to ask for a restore.

Either way, know where your own copy is, how old the oldest one is, and whether anyone has ever restored it.

This month

  1. Ask where your backups are actually stored.
  2. Confirm one copy lives away from your host.
  3. Find the oldest copy you could restore today.
  4. Keep monthly copies for at least a year.
  5. Take a full copy before any move.
  6. Count files on both servers after moving.
  7. Restore one copy to a test site.

Step three is the question that tells you the most. If the answer is a week, the arrangement protects you from last night's mistake and nothing older.

What a hosting plan's own backups usually cover is set out in what a hosting plan includes and what it does not.

Frequently asked questions

What happened to the lost uploads?

A large social site confirmed that music, photos and videos uploaded over roughly twelve years were lost during a server migration. It was a data loss, not a breach.

Aren't my host's backups enough?

Usually not on their own. They exist to restore the host's servers, are often kept only days or weeks, and sit with the same company as the site.

Where should my own backup live?

With a different company, in an account the business controls, with more than one person able to get in, and including both the files and the database.

How long should backups be kept?

Daily copies for a week or two, weekly copies for a couple of months, monthly copies for at least a year, plus an untouched copy from before any move.

What should be checked after a move?

File counts in the uploads folder on both servers, the size of the database, and a sample of the oldest pages, all before the old account is closed.

Why test a restore at all?

Because backups fail quietly: a job stops, an archive lacks the database, or nobody can log in. Restoring to a test copy is the only proof.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Moving your site to a new host?

Talk to us before the old account closes. We will take a full copy and check that every file arrived.

Start a Conversation