A local band collected email addresses at gigs with a paper sheet and typed them into a plugin on their website. After a hosting move, the plugin's data was missing from the new site. The database had been restored from a backup taken before the last two years of gigs.
There was no other copy. The sheets had been thrown away. The band started again from zero and told fans on social media where to sign up.
Their new rule is to export the list monthly to a spreadsheet kept in a different place from the website. The story is a composite, but the shape of it is common: data that lives in exactly one place, a migration that nobody rehearsed, and a backup that was technically present and practically useless.
How the list grew
The band played pubs, village halls and the odd wedding, perhaps three gigs a month in season. At each one the drummer's partner put a clipboard on the merch table with a sheet headed "Join the mailing list" and a biro on a string. People wrote their name and address, sometimes legibly. On the following Monday, somebody typed the new entries into the plugin's admin screen on the band's WordPress site, and that was the whole system.
The plugin kept the subscribers in the site's database, in its own table. Gig announcements went out through the same plugin: write a message, press send, watch it go. Over about four years the list reached somewhere near 1,800 addresses. People on it turned up to shows. When the band released a record, a mail to the list sold more copies in a weekend than anything else they did.
The paper sheets went into the bin once typed up, because nobody wanted a drawer full of other people's handwriting. That seemed tidy at the time.
The move
The old hosting plan was cheap but slow, and the renewal price had risen. A friend who knew a little about servers offered to move the site to a better plan over a weekend. He did it the usual way: copy the files, export the database, import it on the new host, change the nameservers, check the home page.
What he exported from was the problem. The old host's control panel had an automatic backup feature, which he had been told was running. It had stopped working roughly two years earlier, when the account's disk space filled up and the job began to fail silently. The most recent full backup in the panel was dated from the previous summer but one. He used it, because it was the only one offered and the site, at a glance, looked right.
The home page loaded. The gig dates page loaded. The photos were there. The newest blog posts were not, but they were few and nobody noticed until later.
Finding out
The gap surfaced two weeks later, when the band announced a Saturday show and sent the usual message. The plugin reported that it had sent to 640 people. It should have been nearer 1,800. A fan emailed to ask why she had stopped getting news, since she had signed up at a festival the previous year. Her name was not on the list.
Comparing the new site's database with the screen the drummer remembered, the picture was clear. The list ended on a date two years back. Everything after it was gone, and the plugin gave no warning because it had nothing to compare against.
Looking for another copy
The next hour was the usual round of hopeful checks, and it is worth listing them, because most people go through the same ones.
- The old host account had been cancelled after the move. The host's terms said data was deleted shortly afterwards, and a request to support confirmed that nothing remained.
- The old server's backups, such as they were, were the same stale ones.
- The plugin could send a notification email to the admin on every sign-up, but that option had been off since the day it was installed.
- The paper sheets were in a skip, or rather, in a recycling plant, by then.
- Some fans had received earlier mailings, so their addresses existed in other people's sent folders. That was no use for a list the band could legitimately mail.
Nothing recovered the data. In their position the only honest option was to say so.
Starting again
They posted on social media and at the next gig: the old list had been lost in a website move, and anyone who wanted to hear about shows should sign up again, via a link and a QR code on the merch table. About a third of the old list came back within three months, which the guitarist thought was good going and the bassist thought was a disaster.
There was one unexpected benefit. The new sign-up form recorded the date and a short line of text saying what people were agreeing to. The old one had never done that, and the old list had in effect no record of consent. A fresh start, if forced, is at least a clean one. This is general practice, not legal advice, and a band with a bigger list should read the guidance from the data protection regulator.
The routine they use now
The fix was dull and it works. On the first of each month, whoever is on duty exports the subscriber list from the plugin as a CSV file and saves it to a shared spreadsheet account that has nothing to do with the website host. They also keep a rolling folder of the last six monthly files. The website's own backups now run through the host and a second copy goes to a separate storage account, and once a quarter somebody restores one into a throwaway site to see what comes back.
| What | How often | Where it lives |
|---|---|---|
| Subscriber CSV export | Monthly | Shared spreadsheet account, separate from the host |
| Full site backup | Weekly | Host plus an off-host copy |
| Test restore | Quarterly | Temporary site, then deleted |
| Check the newest entry | Before any migration | Compare against the live site |
A migration checklist that would have caught it
The friend who did the move was competent, and the mistake was an easy one. Nothing in his process asked what the freshest data was. A short list, run before the old account is closed, would have exposed the gap while the real database still existed.
- Take a fresh export from the live old site on the day of the move, not whichever backup the panel offers.
- Import it on the new host and open the plugin screens that hold data, not only the pages visitors see.
- Compare counts: subscribers, posts, comments, orders. A total that is a third of what you expected is a finding.
- Keep the old account running for at least a month after the move, and cancel only after a send to the list has gone out and the numbers look right.
The fourth step is the cheapest. A month of a cheap plan costs less than a pint, and the band cancelled theirs the same afternoon.
Checking it yourself
Before any move, and once a year regardless, find the newest thing in your backup and see whether it matches the newest thing on the live site. For a mailing list that is the most recent subscriber. For a shop it is the latest order.
# list the backups and their dates
ls -lh ~/backups/
# peek inside a SQL dump for the newest row
zcat site-backup.sql.gz | grep -i "INSERT INTO .*subscribers" | tail -n 1If the dates disagree, find out why before you change anything else. The troubleshooting guide has a short list of checks for a site that has changed after a move.
Quick answers
Should I trust the host's backups?
Use them, but treat them as one copy, and look at the dates. A backup job can fail for months without anyone being told.
Is a plugin export enough?
For a simple list, yes, if it is kept elsewhere. For anything with orders or accounts, take a full database dump too.
How often is often enough?
Ask how much you could stand to retype. For a band, a month of gigs is a fair answer.
Can I move the list to a mailing service instead?
You can, and it spares you the export chore, but you still want your own copy of the list.