#rclone
Secrets Set to 600, but 0644 Logs Go Offsite Every Night
The .env is encrypted and permissions are locked down on every secret file, but customer data still leaks off the machine every night through something nobody classifies as confidential: logs that every account on the machine can read, bundled into backups uploaded to object storage. Here is how I stop it at the source by logging only result codes.
Every File Is Backed Up, but I Still Can't Rebuild the Server
The database dump is complete, the code tar is complete, and all the secrets are there, but put them on a blank machine and the site will not come up, because the things that actually make the server work were never in the backup files. This article lists what disappears with the machine and the recovery sequence I wrote for my future self.
Backups Succeeded Nightly, but Offsite Uploads Failed for 3 Weeks
cron ran every night, local files were complete every day, and the log said done, but offsite storage had not changed for 3 weeks. The first 8 nights of backups were already gone for good because local rotation had deleted them first. This article examines the two gaps that let the failure stay silent for so long.
Off-Site Backups with Pull Architecture + rclone/rsync
Add off-site Layer 3 to complete 3-2-1 with pull architecture (the destination host fetches the data), rclone + rsync, and lessons from real pitfalls involving NAT, RSA host keys, cwRsync, and PID recycling.