Ruby on Rails电商系统中的压缩与备份实践

为什么要在ref="/tag/2028/" style="color:#B2A89E;font-weight:bold;">Ruby on Rails电商系统中重视压缩与备份

做电商系统的人都知道，数据一旦出问题，损失的不只是订单，还有用户的信任。尤其是在促销高峰期，订单量暴增，数据库和日志文件迅速膨胀。这时候如果没有一套可靠的压缩与备份机制，恢复起来简直像在垃圾堆里找钥匙。

拿一个典型的Rails电商项目来说，每天产生的日志、用户上传的图片、订单导出的CSV，积少成多，一个月下来可能就几十GB。不压缩？硬盘撑不住。不备份？服务器一宕，全白忙。

数据库备份结合gzip压缩

PostgreSQL或MySQL是Rails电商常用的数据库。用pg_dump或mysqldump导出数据后，直接保存原始SQL文件太占空间。更实际的做法是边导出边压缩。

pg_dump myshop_development | gzip > /backups/myshop_$(date +%F).sql.gz

这样一条命令就把数据库导出并压缩成gz文件，体积通常能缩小70%以上。配合cron定时任务，每天凌晨自动执行，既省心又省空间。

处理用户上传文件的增量备份

电商系统里，商品图、头像、发票扫描件这些都存在storage或public/uploads目录下。全部打包备份效率低，应该用rsync做增量同步，再用tar + gzip打包远端归档。

tar -czf /backups/uploads_$(date +%F).tar.gz -C /var/www/myshop/public uploads

压缩完推到阿里云OSS或者AWS S3，设置生命周期规则，30天以上的自动转为低频访问，进一步降低成本。

日志文件轮转与清理

Rails的production.log一天就能上GB，尤其是流量大的站点。直接用logrotate工具管理最省事。

配置文件/etc/logrotate.d/rails-app：

/var/www/myshop/log/production.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    copytruncate
}

每天切一份，保留两周，自动gzip压缩。既防止日志撑爆磁盘，又能留底排查问题。

自动化脚本整合压缩流程

把数据库、上传文件、日志三块的压缩备份写进一个shell脚本，再由crontab驱动，形成完整闭环。

#!/bin/bash
BACKUP_DIR="/backups/$(date +%F)"
mkdir -p $BACKUP_DIR

# 备份数据库
pg_dump myshop_production | gzip > $BACKUP_DIR/db.sql.gz

# 备份上传文件
tar -czf $BACKUP_DIR/uploads.tar.gz -C /var/www/myshop/public uploads

# 打包完成后同步到远程存储
aws s3 sync /backups s3://myshop-backup-store --delete

每周五晚上跑一次全量，平日跑增量，关键时候靠得住。

别等到数据丢了才想起备份。在Ruby on Rails电商系统里，压缩不是优化，是生存必需。