For startups, backup is a lot like security, something you need to have but not something that’s really visible to endusers or that endusers even care about unless of course things go terribly wrong! So in today’s Tech Tuesday I want to talk a bit about backup and will follow up with a broader disaster recovery post.

It used to be not uncommon to encounter super early stage companies that quite literally have no backup strategy whatsoever. It simply didn’t make the cut with everything else they had going on. Thankfully these days most people are in some kind of managed hosting or cloud environment where they have access to a backup service.

Still even today very few of the startups test their backups to make sure they can restore from backup should they need to. Some did it once when they set it up initially. Hardly any test it on a regular basis. Doing so is kind of a pain, but you can really only have confidence in your backups if you periodically inspect them.

Now there are also separate things to backup and sometimes people forget about that or try to use a one size fits all strategy by dumping their DB to a file and then just doing file backups. Instead, I would generally recommend using some native DB backup (meaning specific to the DB you are using), separate backup for files that are not version controlled and finally backup for your repositories. While that is more work it is likely to give you much finer grained control and ultimately better resilience.

And always remember: it ain’t backup if you can’t restore. So please test that!

For startups, backup is a lot like security, something you need to have but not something that’s really visible to endusers or that endusers even care about unless of course things go terribly wrong! So in today’s Tech Tuesday I want to talk a bit about backup and will follow up with a broader disaster recovery post.

It used to be not uncommon to encounter super early stage companies that quite literally have no backup strategy whatsoever. It simply didn’t make the cut with everything else they had going on. Thankfully these days most people are in some kind of managed hosting or cloud environment where they have access to a backup service.

Still even today very few of the startups test their backups to make sure they can restore from backup should they need to. Some did it once when they set it up initially. Hardly any test it on a regular basis. Doing so is kind of a pain, but you can really only have confidence in your backups if you periodically inspect them.

Now there are also separate things to backup and sometimes people forget about that or try to use a one size fits all strategy by dumping their DB to a file and then just doing file backups. Instead, I would generally recommend using some native DB backup (meaning specific to the DB you are using), separate backup for files that are not version controlled and finally backup for your repositories. While that is more work it is likely to give you much finer grained control and ultimately better resilience.

And always remember: it ain’t backup if you can’t restore. So please test that!