云备份数据保留多久？超期被清是常态

备份能存多久，合同里写着，你脑子里那版不算数。云备份数据保留多久超期被清是常态——这不是吓唬人，多数厂商的默认逻辑就是保留周期一到，清理任务自己跑，不打招呼。我接手一个站，第一件事不是看备份开没开，是翻保留策略那一栏填的是几天呢。

云备份数据保留多久超期被清是常态，分档这事儿最容易漏

保留期这东西，基本跟套餐绑着走。便宜的档给的天数短，贵的档拉长一点；再往上，就得单独买归档空间了。控制台里那个“保留天数”多半是个下拉框，选完立刻生效，也不会弹窗提醒你到期会删。我一般会把下拉框截图和开通日期一起丢进项目文档里，隔几个月回来一看——至少知道自己当时选的是哪档吧。

备份不是档案柜。

备份解决的是“最近出事了往回滚”，归档解决的是“半年后审计要查账”，两件事混一起，到头来要么白花钱要么真丢数据。这是我最常见的一个误判，跟技术没关系，纯粹是名词没分清嘛。

清理任务动刀的方式，比你想的安静

后台一般挂着两条线，一条是生命周期策略，按前缀或者标签匹配，到期转低频存储或者直接删掉；另一条是脚本，我见过最土的是往 crontab 里塞一句 find /data/backup -type f -mtime +30 -delete，跑了大半年没人发现，直到有人要恢复三个月前的库才炸出来。想查有没有这类任务，先 crontab -l 扫一眼，再看 /etc/cron.d 里有没有藏东西，容器化部署的去翻编排文件里的定时任务定义。删之前不一定有通知。

到期没人喊你。

有些平台会先把对象标成“待清理”，隔一段时间再真删，中间那段是唯一的窗口期，能不能捞回来全看你发现得早不早呢。所以备份列表里的状态字段得看，别光数条数。

快照和备份，别当一回事

快照是跟卷绑在一起的，源卷没了快照跟着没，而且是滚动覆盖——留几份就覆盖几份，新的一份进来最老的一份就走。有人拿快照当长期备份，主机一重装快照全清空，回头问“我的备份呢”，我也只能摊手。老实说这类事一年能碰上几回，每次都挺无奈。

所以快照不是备份，源卷删了它跟着走，滚动覆盖也留不住老版本。

欠费、退租、注销，会提前触发清理

这几种情况比保留期管用多了。服务到期没续费，实例释放，附带的备份通常跟着走；账号注销前不把数据导出来，指望注销后还能翻回老文件，基本没戏。

宽限期各家给的不一样。

有的给几天，有的干脆不给，具体以服务商公告或者工单答复为准，别拿别人的经验套自己的合同呗。

我确认保留期的几步操作

先把控制台的备份策略页翻出来，看清三件事：保留周期、超期动作是删除还是转归档、有没有跨区域复制。然后翻服务条款和购买页，两边对不上的时候以工单答复为准，答复要截图啊，口头讲的不算数。我一般这么干，麻烦点，但省后患就好。

命令行这边顺手核一下实际文件，ls -lh /data/backup/ 看最近一次的时间戳，sha256sum 抽一个包算个校验值存着，将来恢复前对一遍。不然拿到一个截断的压缩包，你还以为数据好好在那儿躺着呢。tar 包可以先 tar -tzf 只列目录不解压，快得很。

数据库备份有自己的保留逻辑

数据库这块得多说一句。物理备份和逻辑备份的保留周期经常不是一条线，binlog 更是另一套规则，MySQL 里 binlog_expire_logs_seconds 和老版本的 expire_logs_days 控制多久自动清，超了 PURGE 一跑就没了。有人做全量备份做得挺勤，binlog 却没留够，想按时间点回滚的时候发现中间断了，只能回到最近一次全量，中间的活儿全白干。

有些人拿着备份列表里那行绿色的“成功”当护身符，真到要恢复才发现文件是截断的、校验值对不上、解压都解不开，那时候慌也没用。

恢复演练比保留期更能救命

备份躺着不代表能用。我习惯每季度挑一份真恢复一次：解压、校验、导到一个临时实例，跑几条 count 和关键查询，确认数据完整再把临时库删掉。这一套走完通常一两个小时，但比出事那天手忙脚乱强太多。演练时顺便确认恢复出来的库版本跟生产差多少，版本跨太大，导入报错能卡你半天。

没演练过的备份等于零。

想留久一点，几条土办法

重要数据，本地留一份，异地留一份。归档呢，单独买空间，或者定期导到冷存储。说白了，三层都做到位，基本就稳了。导出格式挑通用的就好，sql dump、tar 包这类，别死抱厂商私有格式。迁移那天，你会哭。导出时把表结构和字符集一起带上；只导数据不带结构，恢复起来对不上号。存得越久，账单也跟着长。全量和增量的轮转方式得定期看一眼。增量链一断，往往要重做一次全量，空间和费用都得重算。

给个能立刻做的清单：翻出你现在的备份策略页，把保留周期和超期动作抄进文档；查一遍定时任务里有没有自己不知道的清理脚本；挑一份备份做次恢复演练；给到期日加个日历提醒。这四件事做完，心里就有底了。