If you were building websites anywhere in the early 2000s, you must have learnt this the hard way that you do not buy your domain and hosting from the same provider. If something goes wrong, you end up losing both your domain and access to your hosting control panel. This is still very true and I still see people make the same mistake.
Using your providers backup solution
Using your hosting providers backup solution falls in the same category as buying the domain and hosting from the same provider. Sometimes this backup service is provided free but the majority provide it for a small markup.
Have you ever thought what would happen if you lose access to your hosting providers control panel or dashboard, or if you missed a payment or somehow got wrongly accused of violating their TOS(Terms of Service) or what we see these days where a huge customer base loses access to their accounts as their entire country gets sanctioned.
Remember, backups are for the hosting provider’s convenience and not yours. don’t believe me?, let us look at a few hosts and their Terms,
Rackspace:
you agree that you will maintain at least one additional current copy of your Customer Data somewhere other than on the Rackspace Public Cloud Services. If you utilize Rackspace cloud backup services, you are responsible for performing and testing restores.
Siteground:
We will use good faith efforts to backup data stored on the shared Services once a day (Shared Backups). Shared Backups are intended for internal use only and we cannot guarantee that a Shared Backup will be available for restore upon your request. It is your responsibility to backup data of all your content..
Hostgator:
HostGator backups are provided as a courtesy and are not guaranteed. Customers are responsible for their own backups and web content and should make their own backups for extra protection.
AWS Backup Service:
The Service Commitment does not apply to any unavailability … i) that result from any actions or inactions of you; (iii) that result from your equipment, software or other technology … arising from our suspension or termination of your right to use AWS Backup.
Is using your hosting provider for backups convenient? Yes!
But if you care about your business and your customers, just use another cloud provider or Hosting provider as a backup location. It is considerably cheaper if you go this route as there are dedicated services that provide backup VPSes which are a fraction of the cost that you would pay for a compute instance.
Replicas, Cloud Sync/Rsync are not backups
I have seen a lot of seasoned devs think Database or filesystem replicas to be backups.
Replicas are used for fault tolerance and to increase the read throughput and are not a backup solution.
Imagine a hacker gets in and deletes everything in your database tables, your database replica will instantly apply this delete instruction to its instance thereby deleting data both on primary and the replica instance. The same logic applies to file systems or cloud sync services. It is usually too late by the time you realize that you have lost data in both the locations.
Backup Testing is equally important
I will not get into a lot of detail here as I feel this topic is sufficiently covered on the internet.
To give you a summary, you have to ensure that the backups that you make do actually work as intended and the recovery process is repeatable.
This testing needs to be done on a periodic basis so as to ensure the backup system or automation that you have in place works as expected.
Numbers Matter
Consider you have a Terabyte of data in your database, and you plan to run a backup every night at 01:00 AM and have it stored for 7 days. This would mean the backup on the 8th day would delete the oldest backup and so on.
I purposely chose Database backups as they are very common and don’t work well with incremental backup solutions. This would mean you would need at least 7 TB of disk space for this backup to work.
Now if a hacker or an unfortunate event results in dropping a few thousand rows from less frequently used tables in your database and you notice this after a week, you essentially end up in a situation where you don’t have a backup.
Had you made an additional backup routine which backed up data every sunday, you might not have not lost all the data.
There are no right or wrong solutions here, Each case is unique and you need to make a decision beforehand on how much data you are willing to lose and find a right balance between the cost of operations and the cost of data loss.
sidenote: cloud egress is expensive.
Have a recovery plan
This is probably the most important point and I feel a lot of people just skip this entirely.
If you don’t have a plan yet, right now! open a text file or an Excel sheet and list down the tasks that you need to do if your Database server crashes and assign a person against each task.
- Do you need to re-install the OS?
- Do you need to setup new users and SSH keys?
- Do you have to re-install the DB server?
- Who, When and how will I notify my users?
- How long will the recovery procedure take?
- Where is all the documentation?
- Meanwhile, can other services/DBs introduce side effects in their state or go out of sync?
- What services might need a restart once the recovery is completed?
These are a few examples but you definitely need to put this on paper and repeat it for other things like assets, media or any other files and folders.
If you care about your users, your hard work and your data, Have backups and have a backup plan.
If you liked this article, please share it with your friends and office mates who are waiting for their tests to pass 😊
I would love to hear how you do backups and if you have any interesting backup strategies or stories to share.