Last month I launched and renamed my little side project Stackable. It’s now called WP Freighter. With development of that more or less completed, other then support, I’m happy to be back working on CaptainCore development 😃. Hurray!
This month, let’s talk about website backups. Backups within CaptainCore have always been treated as a last resort option. I mostly rely on my host provider backups, which go back the last 30 days. Within CaptainCore each WordPress site is incrementally synced into a B2 bucket on a daily basis. It’s a very cheap and efficient backup. However that means I can only fully restore the last backup, which is a big limitation.
Ironically, CaptainCore out started as a bulk backup script which I used to backup hundreds of WordPress sites with a simple one line bash command. Check out my crude backup.sh from 3 years ago in my initial CaptainCore commit. It’s well overtime to revamp this initial feature of CaptainCore.
Creating backup snapshots and storing them gets expensive, especially at scale.
Recently I’ve become interested in Restic as a potential solution for longterm backups. I’ve been using Restic for personal backups and it works amazing well. Last month I set out on an experiment to see if I could revamp CaptainCore backups with Restic. Here are the results.
- Productions websites are incrementally synced to the CaptainCore instance and now pushed into Restic repos stored on B2 buckets. Each site environment has it’s on Restic repo. Checkout my post WordPress Backups with Rclone and Restic for a basic understand of this workflow.
- Revamped backup interface with ability to download files or folders from any Restic snapshot.
- Large backups, with more then 50,000 items, will omit individual upload files from the restore interface for performance sake. All files are still restorable on a per folder level.
- Expanded default exclusions for to keep backups lean and running smooth. Will need to expand this list as I find more unwanted files in my backups.
Restic backups are de-duplicated and encrypted.
That means if you backup a 10GB WordPress site every day for a year the Restic backup repo will only grow as new content is added. If, over the course of the year, an addition 5GB is changed then your Restic backup repo would grow to 15GBs. That’s huge difference when compared to regular snapshots which would require at least 365GB to maintain a year’s worth of 10GB snapshots. Restic backups are full restorable to any previous backup point.
Here is a sneak peak at what the restore UI looks like.
I’m still keeping the 2 other backup options, quicksaves and snapshots. The restore UI simply adds a 3rd new option to the backup tab located within each site environment. Quicksaves is my go to for maintenance troubleshooting. That said quicksaves was never meant to be used a replacement for backups. It’s just an awesome way to quickly troubleshoot and resolve compatibly or code related issues.
Within each backup, files or folders can be selected and then downloaded as a zip. Generating the restored files can take some time so an is email sent once it’s ready for download. Here are a few screenshots showing the new section. Until next month, onward!