.env.backup.production ★

# Validate syntax (for Node.js apps) node -e "require('dotenv').config(); console.log('DB_HOST:', process.env.DB_HOST)" curl http://localhost/health Reload the process manager pm2 reload app # or: systemctl reload app Common Pitfalls and How to Avoid Them Even experienced engineers mishandle .env.backup.production . Here are three frequent mistakes. Pitfall 1: Backing up invalid state If your production environment is already misconfigured (e.g., an expired API key), your backup will be equally broken.

Additionally, integrate this into your CI/CD pipeline. Every successful deployment that changes environment variables should automatically trigger a backup before the mutation. .env.backup.production

Use environment variables to define the backup location. # Validate syntax (for Node

#!/bin/bash # /usr/local/bin/backup-env.sh TIMESTAMP=$(date +%Y%m%d_%H%M%S) BACKUP_DIR="/var/backups/env" SOURCE_ENV="/var/www/app/.env.production" cp "$SOURCE_ENV" "$BACKUP_DIR/.env.backup.production.$TIMESTAMP" Maintain the generic '.env.backup.production' symlink ln -sf "$BACKUP_DIR/.env.backup.production.$TIMESTAMP" "/var/www/app/.env.backup.production" Retention: keep only last 30 backups find "$BACKUP_DIR" -name ".env.backup.production.*" -mtime +30 -delete Additionally, integrate this into your CI/CD pipeline

Because when the disaster comes—and it will come—you want to be the engineer who types cp .env.backup.production .env.production and goes back to sleep. Your future self, at 3 AM during a Sev-1 incident, will thank you.