I read a lot about backup but the most important points that I noticed throughout my life as a developer are rarely listed.
Backup is a mix between security, automation and low-level understanding of your application (and OS). It's a good exercise for every developer.
- It help to learn how your applications and system works. For each application you should find where is the data, which format is used (and why) and which tool you can use to get plain-text version of the data. You can learn a lot about your OS, web browser and games.
- You can duplicate your dev workstation easily: save your developer setup on a USB key allow you to access your Linux alias, IDE configuration, bookmarks, notes and snippets everywhere. It's an easy way to share you tips with your peers and work on someone else computer.
- Hardware and Software failure: your SSD is not invulnerable and despite all the tests, any application or OS can corrupt data during update or running. If you are developer maybe you know that unit test covers application functionality and rarely data consistency after migration.
- And the most famous: ransomware, thief, revenge, house in fire or under water, emergency evacuation, small child, fall of a magnet on your HDD, accidental "rm -rf" etc.
There is requirements you should keep in mind:
- You must be able to restore/access the data with any other computer (and/or another OS). The perfect solution is a backup file you can restore with Live OS (boot on USB key).
- Software should be easy to install on your host (computer/smartphone) and easy to use.
- The output file format should be common: so you can write an automated test on your backup pipeline: backup folder containing one text file, verify the file is present and the content of this file.
Many tools may be good for this job and by the way you can build your own backup script with Python (or any shell language), rsync and cron jobs.
- Set up alert when backup fail. A good way is to configure a independent CRON job to verify the most recent backup file is not older than 2 days.
- Test your data restoration frequently in real condition (using VM or container).
- Cryptography is essential for personal data but remember to ensure you can restore data easily in any context (another OS/platform and version).
- Automation is the key (cron) but beware this automation doesn't silently delete data. One of your duplicated should only add new files and never repeat (on the remote) the local deletion of a file.
- 3-2-1 rule: see this post - Remember something like 4-3-2 is better :)
- I often use USB key and SD card: they are compact (portable), waterproof, shockproof and easy to put in a little fireproof vault. Moreover it can be full-time connected to your computer as simple RAID1 solution against hardware and software failure.
- Ransomware infects all device connected to network so NAS and RAID1 solution, it's why an off-site and offline storage is important. Cloud storage is a good alternative if your hosting company pass your privacy requirements :)
- My backup strategy is divided into 2 channels: personal data (rarely updated and encrypted) and work data (modified everyday but doesn't need crypto). So I have two distinct process and allocated storage to avoid my every-day backup doesn't raise problem to my important.
- Install and test recover software (for example PhotoRec) it may be helpful.
- Personal data: pictures, phone-numbers, scanned files
- Internet data (browser relative data): bookmarks, passwords, important e-mails and/or downloaded files
- Online services: a copy of everything you create directly online (without copy on your local host) like blog post.
- Game level backup ;)
- Development stuff: projects, IDE configuration, gitconfig, Linux alias (bashrc), git hooks, API keys, docker-compose files, paid resources (icons, libs, ...)
- External data: data stored in databases
- External support: backup is necessary for your 2AF solutions like Yubikey, or have a fallback for Android application without degrading security level.
- OS configuration: firewall rules, SSH keys ...