备份与连续性
出了问题会怎样：信息多久复制一次、副本存在哪里、可以恢复到哪个时间点。
两套相互独立的备份
信息通过两条相互独立的途径备份。只有一种备份机制，就是单点故障：它要是悄无声息地坏了，你会在需要它的那天才发现。
| 机制 | 频率 | 存放位置 | 保留期限 |
|---|---|---|---|
| 时间点恢复 | 持续 | 数据库服务商的基础设施 | 取决于所订购的套餐 |
| 数据库完整备份 | 每天 | Cloudflare R2，与数据库分开存放 | 30 天 |
每日备份放在另一家服务商那里，是有明确原因的。备份如果和数据库放在同一套基础设施上，就会和它共用同样的故障模式：服务商一旦出了严重问题，两份会同时丢失。
时间点恢复
它能把数据库恢复到某个精确的时刻，而不只是最近一次备份的时刻。它针对的是最常见的数据丢失情况：不是服务器宕机，而是人为失误，比如 10:47 的一次误操作批量删除。
恢复是在一个新的服务上进行的，不动正在生产环境里运行的那一个，所以可以先核对内容，再决定是否切换。
核查
最近一次备份的状态（什么时候运行、是否成功完成、大小多少、有没有出错）通过平台的健康检查接口公开，我们每次发布后都会查看。
没人查看的备份只是一种假设，不是保证。备份几乎从来不是因为不存在而失败，而是因为三周前就停止运行了却没人发现，因为这段时间里没有任何看得见的东西坏掉。所以我们把状态公开出来，而不是只留在日志里。
可用性
Nodux 目前不提供带违约赔偿条款的服务等级协议。我们不公布保证可用性的数字，因为我们还没有足够的实测历史来支撑它，没有这些就去承诺，那只是一个编出来的数字。
我们有的是：正常情况下发布时没有可察觉的中断，带错误告警的监控，以及一个任何人都能查询的公开健康检查接口。
如果你的企业需要书面的可用性承诺，请写信到 soporte@nodux.link，我们结合你的具体情况来谈。
如果你丢失了信息
请尽快写信到 soporte@nodux.link 或通过 WhatsApp 联系我们，说明丢了什么、大概是什么时候。越早通知，恢复越简单。如果是误删，之后的操作越少，需要核对的东西就越少。