关键在密钥管理、算法选择与压缩加密顺序：必须用openssl_encrypt+aes-256-gcm，iv随机且附带，密钥经pbkdf2派生，先tar/gzip再加密，上传前校验sha256，密钥须环境变量或vault管理，且务必验证解密流程。
本地加密备份文件再上传云端，关键不在“能不能做”，而在“密钥怎么管、算法怎么选、压缩和加密顺序怎么排”——这三个环节出错，备份就等于没备。
用 openssl_encrypt 而不是 mcrypt 或自制 XOR 加密
mcrypt 已废弃多年，PHP 7.2+ 直接报错；XOR 加密看着简单，但无认证、无随机 IV、无法抵抗重放或篡改，云存储场景下等同于明文。
- 必须用
openssl_encrypt+AES-256-CBC或AES-256-GCM（后者支持完整性校验，更推荐） - IV 必须每次随机生成，且和密文一起保存（比如前 16 字节），不能硬编码或复用
- 密钥不要用密码原文，要用
hash_pbkdf2('sha256', $password, $salt, 100000, 32, true)衍生，盐值单独存或随文件附带 - GCM 模式下记得提取并保存
$tag（16 字节），解密时必须传入，否则验证失败
先压缩再加密，别反过来
压缩率会因加密后数据熵值拉满而归零——如果先加密再压缩，gzencode 或 ziparchive 基本压不出体积，还白耗 CPU。
- 正确顺序：
tar → gzip → openssl_encrypt - 用
proc_open管道链式处理，避免中间写临时大文件（比如 10GB 备份包） - 示例片段：
$proc = proc_open('tar -cf - /data | gzip -c | openssl enc -aes-256-gcm -pbkdf2 -iter 100000 -salt -pass pass:"'.$password.'"', ...); - 注意：
openssl encCLI 版本默认不输出 GCM tag，得加-authentictag参数，并用stderr读取 tag，再拼到输出流末尾
上传前校验完整性，别只靠 HTTP 状态码
HTTP 200 不代表文件没损坏——尤其分块上传或网络抖动时，云厂商可能只接收了部分字节。
立即学习“PHP免费学习笔记（深入）”；
- 本地计算加密压缩后文件的
sha256_file()，上传后调用云 API（如S3 HeadObject或MinIO statObject）比对Content-MD5或自定义元数据x-amz-meta-sha256 - MinIO/S3 支持在
PutObject时传Content-MD5，服务端会校验，不匹配直接 400 - 别用
md5，它碰撞风险高，云存储长期存档必须用sha256
密钥管理是最大单点故障，别藏在代码里
把密码写死在 PHP 文件里，等于把保险柜钥匙焊在柜门上。一旦服务器被黑，所有备份瞬间裸奔。
- 生产环境必须从环境变量读密钥（
getenv('BACKUP_ENCRYPTION_KEY')），并确保该变量不进日志、不进phpinfo() - 更稳妥做法：用本地
keyring（Linux secret-tool）或 HashiCorp Vault，PHP 通过 cURL 拉取短期 token 化密钥 - 定期轮换密钥？那就得保留旧密钥解密老备份，同时新备份用新密钥——密钥版本必须嵌入文件名或元数据，比如
backup_v2_20240520.enc
最常被跳过的其实是解密验证环节：写完备份脚本后，90% 的人没真跑一次解密还原流程。等真要恢复时才发现 IV 长度不对、tag 丢了一字节、或者 GCM 认证密钥长度误用了 24 而不是 32——这时候删库跑路都比翻日志快。
