Everyone agrees that backups are essential. Not only for websites but also for desktops, laptops, phones, and even git repositories. Yet, when it comes to protecting mission-critical WordPress sites, the backup solutions in place are often inadequate.
More often than not, these backup shortcomings are a result of myths and assumptions about the underlying infrastructure your site runs on. Here are several myths I come across when onboarding new clients.
Myth 1: My site uses EBS, which is replicated across multiple servers. I don’t need backups.
While it’s true that EBS volumes are replicated across multiple servers, they are not protected against any file changes or deletions done by the user. Failed WordPress updates, user error, or malware can alter files on your server. If you don’t have a backup solution in place, EBS can’t recover file changes or restore older versions on demand.
Myth 2: I store my media on S3. I don’t need backups.
Similar to EBS, storing WordPress uploads on S3 is also not an alternative to backups. Without backups, any files deleted from wp-admin even by mistake are lost forever. One caveat to this is if you enable versioning on your S3 bucket, it protects against file changes and deletions. Remember that this is not enabled by default. If your site offloads static assets to S3, make sure that versioning is enabled and working as expected.
Myth 3: AWS takes snapshots of my server. I don’t need backups.
While snapshots are better than not having any backups, restoring them is time-consuming and costly. Imagine your team asking for a copy of wp-config.php from last week. Backup archives can selectively restore this one file in seconds. Server snapshots, on the other hand, need to be restored entirely on a new volume before any files are accessible. If you restore server snapshots on a new instance, there is a risk of wp-cron altering the database with stale values. Snapshots also make local development difficult compared to backup archives.
Myth 4: I don’t need to backup dev sites.
While chances of data loss on development sites are smaller compared to production, these sites should still have a backup solution in place. Development site backups enable developers to rollback 3rd party libraries to previous versions when things go wrong. Backups also protect against dependencies that are no longer available on public repositories, software bugs that result in malformed artifacts, and more.
Myth 5: I don’t need to backup git repositories
Git repos are distributed by design. Most teams also sync with git hosting services such as Github or Gitlab. So does it make sense to backup git repositories? In a high-availability environment, git hooks are often used for various post-deployment tasks. These hooks are not present on developers’ local repos or Github. Having a backup of the git repository on the server protects these hooks in case of a disaster. Git backups are a lifesaver in the event of cloud and SaaS outages.
A good backup strategy contains the following three elements:
Frequency: Backup frequency should be adjusted depending on how frequently your site and database change.
Destination: Backups should be stored in at least 2 separate regions to protect against any cloud outages.
Verification: Backups should be tested periodically to ensure the integrity of the archives.
Once you have a backup policy in place, you can start looking into the performance impact and overhead of your strategy.
Top comments (0)