如果你有大量的数据——大于 2TB 的数据，需要非常安全可靠的存储，同时这些文件的访问频率低于一年两次，那么最佳的选择是什么呢？本文将介绍我结合 AWS Lightsail，使用 S3 Glacier Deep Archive 存储的方案，实现了最低 $0.99/TB/月的低价云存储。

市面云存储价格对比

TL;DR 考虑到成本和最大容量问题，我使用 iCloud 作为小数据的 “热备份”，使用 S3 作为大文件的 “冷备份”

在进入正题前，我们来对比一下目前市面上的几个存储方案，这里只对比面向个人的存储方案；你也可以直接跳到 Nextcloud 章节。Google Workspace、Apple Business 等面向企业的存储方案往往溢价更高，这里不再做对比。这里所展示的价格为美国区不含税的价格。一些服务会对其他国家有价格歧视 (低价区)，这不是本文所讨论的范围。

1. 使用年费方案，Google Drive 和 OneDrive 会更便宜一些，详情参见官网。
2. OneDrive 并不提供 6TB 的个人套餐。该套餐为家庭套餐，可供 6 个账户使用，每个账户提供 1TB 存储空间。
3. Mega 的流量是有所限制的，详情参见官网
4. Adobe 需要配合其他订阅 (至少 $9.99/月) 才可以购买空间

价格分析

苹果和谷歌都提供了 $9.99/2TB/月 的存储方案，2TB 对于绝大多数人已经够用，甚至还有点多。苹果和谷歌的更高级的套餐可以与包含自己在内的 6 个人进行共享。微软提供了 $6.99/1TB/月的存储方案，该方案还包含了 Office 套件。相比之下，微软的家庭版套餐提供更高的总容量，但每人限制 1TB 而非 6TB 共享，使得其不是那么的灵活。

根据自己的使用习惯，苹果、谷歌和微软可能也没有多少选择。如果全家都是苹果全家桶用户，那么就直接苹果的 2TB 家人共享就很合适。如果是 Windows 用户，同时是 Office 使用者，那微软的方案是最合适的。如果是 Google Photos 的用户，或者经常使用 Google Workspace 来写文档，那么选择谷歌是更好的。

此外，苹果最新的系统中可以开启 iCloud 端到端加密，开启后所有文件、照片都是端到端加密的。而上述其他的服务商则可能不提供端到端加密，或者是只有部分文件夹是端到端加密。

Dropbox 的跨平台做的不错，我用过它的 Mac 和 Windows 客户端，都非常高效好用。我曾经在 Mac 上使用微软的 OneDrive，体验就极其糟糕。

Google Workspace、Dropbox Teams 则提供了所谓 “无限容量” 的套餐，但所谓无限容量，其实是价格不透明。当使用量足够大的时候，不排除被限制的情况。因此本文只对比有明确标明容量和价格的套餐。

如果需要更大的套餐 (>2TB)，那么可以将目光转向 Mega。Mega 提供单位价格更低的网盘服务，同时支持完整的端到端加密。

值得一提的是，Mega 最近也推出了 Pro Flexi 套餐，起价 €15.00/3TB/月，在此基础上 €2.50/TB（流量也是 €2.50/TB），最高可以用到 10,000TB。

如果你使用 Lightroom CC 管理照片，且你的照片是存储大户；或者使用 Premiere Rush 剪辑视频，并且视频是存储大户，那可以选择 Adobe Creative Cloud 的存储空间，最高可以存储 20TB。

我的选择

如果 2TB 对你而言足够，且在可预见的未来也不会很快超过 2TB 的存储需求，那么直接选苹果、谷歌、微软、Dropbox 中的一个就行了。如果有大量的 RAW 照片需要存储，那么 Adobe Lightroom CC 则是不错的选择，$9.99/月的 Lightroom 就包含了 1TB 存储空间，加到 $19.99/月就可以有 3TB 存储空间，能随时随地访问到整个图库还是很方便的。

我就有在用苹果的 2TB 套餐，用 iCloud 同步一些小，但经常访问的文件还是很方便的。我也用 iCloud Photos 来同步 iPhone 拍摄的照片和视频，以及导出的全尺寸的 JPEG 和剪辑后的视频。此外，我还用 iCloud 对我的 iOS 设备进行备份。iCloud 是我的 “热备份”。

此时我还需要备份相机录制的 MP4、RAW 视频和 RAW 图片，这些文件有数 TB，并且每年还会以几百 GB 的速度增长。这些文件通常不需要随时访问，此时就需要 “冷备份” 了。我体验过一年 1TB 的 Lightroom CC，1TB 的容量对我而言虽然够用，但我的存储量还是会持续增长，不想将来不停的升级到越来越贵的套餐。因此最近又换成了同样价格的 Photography Plan，少了 1TB 的云存储，但多了 Photoshop。

我没有怎么体验过 Mega，但 Mega 确实也曾在我的考虑范围内。最终我没有选择 Mega 的原因是因为它不够便宜。的确，$2.03/TB/月的 16TB 套餐是很便宜了，但如果你只需要用 9TB 呢？此时还是得订阅 16TB 的套餐。而且哪怕用到 16TB，它还是比 S3 Glacier Deep Archive 贵了一倍多。

因此我选择了部署在 Lightsail 上的 Nextcloud 作为冷备份的系统，S3 作为存储后端。同时通过 S3 桶生命周期，实现智能调整文件的存储级别，实现了最低 $0.99/TB/月的云存储。Nextcloud 可以选择开启试验性功能 “Virtual File Support”，可以有选择性的同步文件。（Mac 上需要修改 ~/Library/Preferences/Nextcloud/nextcloud.cfg，在 [General] 下增加 showExperimentalOptions=true）

我使用的图像编辑软件是 Adobe Lightroom Classic，我的所有 RAW 照片都是用 Lightroom 管理，原图存储在 Nextcloud 同步的文件夹中。我使用 Lightroom 对所有图像生成了 Smart Preview。在本地空间不足，Nextcloud 清除了老文件时，仍可以使用 Smart Preview 预览和编辑图片，并导出小尺寸的图片。Lightroom Classic 也可以通过 Adobe Creative Cloud，将 Smart Preview 同步到支持移动端的 Lightroom CC 上。这部分的 Smart Preview 是不占用 Adobe 的云空间的。Lightroom Catalog 我存放在本地的默认位置，但其备份存储在 iCloud。

视频剪辑软件我使用的是 Final Cut Pro，我的相机产生的所有视频都使用 Final Cut Pro 管理。Final Cut Pro 可以配置资料库中媒体的存放位置，我将其设置为 Nextcloud 的文件夹。这也是主要占空间的文件。Final Cut Pro 的资料库我存放在本地，其备份存储在 iCloud。

为什么不用 NAS？

前年的时候，我在Mac mini 有什么用？组建家庭服务器！ 里提到我使用 Mac mini 作为 NAS 使用。但当时我只是用它来进行备份，而非云存储。如果用自建 NAS 做云存储的话，出门在外访问则很成问题：最主要的就是受到 NAS 所在网络的上传速度限制，从而体验很差。在我的印象里，哪怕是成熟的 NAS 解决方案，也没有一个 NAS 能提供像 Dropbox 这样好用的全平台客户端。此外，单个的 NAS 并不可靠，因为它没有在物理上跨区域。NAS 中的硬盘也有购置成本，硬盘老化后也有更换成本，自己维护起来还有时间成本，最终未必划算。

如今，我把我的所有文件都放到了云存储，不再需要备份，因此也不再需要用 NAS 再备份一遍云存储中的东西了，只用来做 Mac 的 Time Machine。

Nextcloud

Nextcloud 是一整套自建云存储的开源解决方案，从服务端到客户端均有，并仍在持续更新中。跟它极为相近的还有 ownCloud 也是可选的方案。本文将简单介绍我选择的 Nextcloud。不过既然使用 S3 了，为什么还需要服务端？为什么不在本地直接使用 S3 备份工具/挂载工具？因为我是想自建一个类似 Dropbox 的云存储，可多个设备本地实时的同步，没有额外服务端是实现不了或者很难实现的。

为 Nextcloud 选择一个服务器尤为重要。这里我选择 Lightsail 的原因是，Lightsail 可以与 S3 在同一个区域 (Region)，之间的延迟很低，并且 Lightsail 与同可用区的 S3 之间的流量是免费的。此外，Lightsail 的很便宜的套餐也有很多的流量可以使用。

我在云服务推荐及选择指南这个文章中也列举了一些其他服务商，他们也可以作为替代 Lightsail 的选择。虽然他们并没有连接 S3 的优势，但一些服务商有提供自己的对象存储解决方案（比如 BuyVM 提供 Block Storage Slab，Google Cloud 提供 Cloud Storage 等）。

对象存储对比

除了亚马逊的 S3 外，微软 Azure、谷歌云也提供与 S3 类似的对象存储。微软 Azure 的 Archive 与 S3 Glacier Deep Archive 在功能和价格上都十分相似，在此不再额外介绍 Azure 的对象存储。谷歌云则有些不一样，我在这里对比一下价格。这里以最便宜的区域为例：

1. 传输到中国大陆地区为 $230/TB，传输到澳洲为 $190/TB。下面计算费用是以其他地区的 $120/TB 计算的。

假设需要存储 10 TB 的文件 10 年，S3 Glacier Deep Archive 的总费用为 $0.99 x 12 x 10 = $118.8；Google Archive 的总费用为 $1.20 x 12 x 10 = $144；S3 Glacier Instant Retrieval 或 Google Coldline 的总费用为 $4.00 x 12 x 10 = $480。

• 需要立即下载一个 1TB 的文件在我的电脑上，S3 Glacier Deep Archive 是不支持的，S3 Glacier Instant Retrieval 需要 $20 + $90 = $110，Google Coldline 需要 $20 + $120 = $140，Google Archive 需要 $50 + $120 = $170。
• 如果可以接受在 12 小时后下载一个 1TB 的文件在我的电脑上，S3 需要 $20 + $90 = $110。对于不需要立即访问的数据，Deep Archive 之外的没有优惠。
• 如果可以接受在 48 小时后下载一个 1TB 的文件在我的电脑上，S3 需要 $2.5 + $90 = $92.5。

所以，对于不需要立即访问的文件，S3 Glacier Deep Archive有着绝对价格优势。但如果有立即访问的需求，S3 的 Glacier Deep Archive 是不支持的，Glacier Instant Retrieval 存储费用相比 Google 更贵，但取回费用相比 Google 更便宜。

由于 S3 的 Glacier Deep Archive 更加便宜，因此我最终选择了 S3。

Lightsail 与 Nextcloud 服务器配置

Lightsail 我选择了 $5/月的套餐，这个套餐是最具性价比的，包含了 2TB 的流量，同时 CPU 基线也来到了 10%。我这几天实际体验下来，Nextcloud 在不间断上传文件时 CPU 占用在 15-20% 左右，其他时候保持同步占用仅为 1%。也就是说每天可以有 12 小时的上传文件。

Nextcloud 的安装参考 Nextcloud 官网即可。我使用的是 Ubuntu 22.04，官网上给出了这个发行版的安装指南。安装完成后，可以参考 Server tuning 进行优化。我配置了 Redis 和 APCu，开启了 JIT 等，减少 CPU 负载。

Nextcloud 可以选择将 S3 作为 Primary Storage。我不推荐这种做法，因为 S3 作为 Primary Storage 时，S3 存储桶里只保存文件本身，不包含文件的元数据 (包括文件名、目录，因为此时元数据只存在于数据库中)，也就是说这时的 S3 的桶是不能直接访问的，只能通过 Nextcloud 访问文件。此外，将 S3 作为 Primary Storage 还会导致性能下降，因为 Nextcloud 会将分段上传的临时文件和 App data 也存在 S3 中，分段上传大文件 CPU 占用极大，且经常出现超时 (已经提优化 issue，欢迎点赞支持)。

Nextcloud 还提供 External Storage 功能，安装完毕后，通过 External Storage 挂载的 S3，其文件结构是保留的，也就是说此时 S3 的存储桶是可以直接访问的。我觉得这个还是很重要的，省去了我备份 Nextcloud 数据库的烦恼。此时就算 Nextcloud 整个实例挂了，我的所有文件都可以在 S3 存储桶里访问。如果将 External Storage 的挂载点配置为 /，那么根目录下所有文件和文件夹都是和 S3 同步的，十分方便。

此外，我会关闭 Nextcloud 的 Deleted Files 功能，并通过 S3 Versioning 实现版本管理。因为 Deleted Files 开启后，删除文件时，Nextcloud 会将 External Storage 中的文件移动到本地，这样会费时、费钱且占用本地空间。

本地 SSD 空间不够

尽管已经通过 External Storage 将所有文件存储在 S3，但 Nextcloud 仍会将分段上传的视频存储在本地的 /var/www/nextcloud/data 中，此外 PHP 也会将上传的文件临时存储在 /tmp，除非另行配置。因此，当上传的文件很大时 (比如同时上传多个十几 G 的文件)，会超出 Lightsail 本地 SSD 的限制，导致本地 SSD 空间不够。

升级 Lightsail 的配置，或者在 Lightsail 上挂载 SSD 都是增加固定的存储容量，这并不划算。因此，推荐使用 EFS，将网络存储挂载到本机，修改 Nextcloud 的 data 目录到挂载点。参考 AWS 指南 How to Use Amazon EFS with Amazon Lightsail。EFS 是根据使用量按量计费的。只有存在尚未完成的分段上传时，Nextcloud 的 data 目录才会有大文件在，因此 EFS 按量计费十分划算。

EFS 使用 Burst、One Zone 模式即可，这也是最便宜的方式。实测 EFS 的性能比 s3fs 挂载 S3 好很多。

S3 生命周期

更多内容待补充，如有问题欢迎在下方评论

2022 年 12 月 18 日，阿里云香港服务出现了异常。本站所用的香港服务器也中招，由于本人不正确的报警配置，导致部分域名没有正确切换解析，造成了一小部分用户最长半小时的不可用。然而，阿里云香港机房出现问题的时间远不止一个小时。根据我这里的监控，自北京时间 10:49 开始，我跑在香港阿里云上的 HTTP、HTTPS 服务就完全不可用了，直至 20:46 才恢复，共计宕机时间 10 小时。

事故回顾

本人是在早上起床后就发现阿里云香港服务器不可用。一开始以为是被神秘力量封锁了，但是看到报警邮件后发现，香港服务器在国外其他地区也不可用。

然后我就测了一下，发现主机能 ping，但无法 SSH 上去，HTTP/HTTPS 服务亦不可用。此外，yangxi.tech 网站服务也受到了影响。然后我登录了 AWS 中国区的 Route 53 去查看报警，结果发现 Route 53 上没有任何报警（我的 guozeyu.com 和 yangxi.tech 都在用中国区 Route 53）。查看最近的监控，发现我在 Route 53 上有一处配置错误，导致程序实际上没有在监控香港阿里云……于是修改了监测规则。此时我登录了 AWS 国际区，发现国际区的阿里云香港监控是在正常报警，发现是从 10:49 开始，全球所有监测点均不可用。

由于此时 AWS 中国区的报警已经被我改成正确的了，所以已经根据规则，在 DNS 层面进行自动宕机切换了；而且，我之前配置的 DNS TTL 也仅有 120 秒，所以我的所有网站应该在 11:20 前就已经完全恢复正常了。如果没有错误的报警规则，我的网站总共宕机时间也不会超过 5 分钟。

然后我登录了我自建的 Observium 监控，不出意外的看到了阿里云香港的机器已经宕机了。但我发现在宕机前，服务器的 CPU 是 100%。我就怀疑这是不是我自己服务器上某个程序卡死了，占用了所有资源，导致看起来 HTTP/HTTPS/SSH 服务都不可用了。

此时已经 11:30 了，我还觉得这个是我自己的问题，毕竟我也没收到阿里云任何邮件、电话提醒。于是我登录了阿里云后台，尝试进行重启。此时我没有选择强制关机。结果，关机指令已经执行了 10 分钟，机器仍未关闭。平时我使用 GCP 时，如果关机指令执行超过两分钟，那么就会自动执行强制关机，所以此时执行了 10 分钟的关机就很离谱。然后我就尝试发工单，但没能进入到工单，被转到了在线客服。我向在线客服描述了问题后，无人回复。然后我又尝试发工单，结果工单也是无人回复。只是得到了机器人回复，说在关机时，Windows 会执行系统更新，有时需要 10-15 分钟。请在等待 20 分钟后联系客服。

大概又过了半个小时，机器终于成功关闭了，但在尝试多次后，机器无法启动。即便我点了启动，机器也会在一段时间后变成 “已停止” 状态。由于此时我还是以为是我自己的问题，不是阿里云的问题，我以为是刚刚强制关机导致系统损坏了，于是尝试给现有云盘打快照，尝试回滚。但离谱的事又发生了，我发现我根本无法打快照！快照的进度一直是 0%。

在 11:55，我终于收到了工单的回复：“您好！阿里云监控发现香港地域某机房设备异常，影响香港地域可用区C的云服务器ECS、云数据库polardb等云产品使用，阿里云工程师已在紧急处理中，非常抱歉给您的使用带来不便，若您有任何问题，请随时联系我们”。此时我才知道，这次的宕机可能不是我自己的问题，我放弃了自己尝试恢复服务。

该回复没有提供解决方案，也没有预计的恢复时间，可以说无非就是告诉了我 “这个是我们阿里云的问题”，对于恢复服务没有实质性帮助。

无力吐槽阿里云

本次事件最值得吐槽的地方是，我从未收到阿里云发来的有关通知。直至现在，我在邮箱、短信、站内信中没有收到任何阿里云关于此次服务宕机的提醒。我相信阿里云是有很多监控的，我坚信阿里云早在我发现我的服务出现问题之前，就已经知道了我的服务，以及其他人的服务器出现了问题了。但我却没有收到任何通知。唯一告知我阿里云存在问题的还是我发工单自己问出来的。

我觉得阿里云有必要向所有受影响的，以及可能受影响的客户发送相关提醒。在连续宕机了 8 小时，且仍未恢复的情况下，阿里云仍不主动通知客户，我实在是难以怀疑阿里云是否是故意不做通知，试图掩盖问题。

那还用阿里云吗？

会的。作为中国第一大，以及全球也能排的上前几的云服务商，我不怀疑阿里云的技术实力。我现在用阿里云主要是为了阿里云香港的 CN2 精品网，用于数据跨境（价格为 3元/GB）。目前在这方面也没有什么可替代的方案。专线也考虑过，太贵了，买不起。

但是，我不会把核心业务放在阿里云上了。放在 AWS 上我更安心一些。本次阿里云香港宕机只影响了我的网站一小会儿，也正是因为我没有把核心业务放在阿里云上。

本站是如何做到高可用的？

很简单，本站在四个地区，使用了四个不同服务商的服务器：

• 德国 OVH
• 北京 AWS
• 香港 阿里云
• 美国 Google Cloud

而且本站是纯静态网站。本站会在构建后，将构建产物分别同步到四个服务器上，没有主服务器的概念。本站通过 GeoDNS，将访客解析到最近的服务器，以降低延迟。在阿里云香港服务器宕机后，只需要停止响应解析即可。原本亚太地区解析到香港，现在亚洲会解析到北京，澳洲会解析到美国，这部分用户就被分流到可用的服务器上了。

本站还使用了 Route 53 的 Health Check 功能，可以实现接近实时的监控主机运行状态，在发现运行状态异常时，自动停止响应解析。目前，我的网站会在出现异常后一分钟内检测并识别到，并停止响应解析。相关 DNS 记录的时间设置在了 120 秒，因此服务发生不可用时，用户影响的时间不会超过 3 分钟。

谁也不希望丢失数据，但这很难避免：文件误删除、意外停电、硬盘损坏、硬盘丢失、自然灾害……以上这些都会导致数据丢失，并且很可能无法直接恢复。相信很多人都有过这样的苦恼。本文将简单介绍备份的 321 原则，以及云端备份和本地备份的最佳实践。

典型的数据丢失案例

• 比如 GitLab.com 的运维人员就曾经误删除过数据：2017 年 2 月 1 日，运维人员使用了 root 账户错误登录到了主服务器上删除了核心服务数据。更严重的是，其中有五种备份方式都失效了。但幸好还留存着一个六小时前的备份，尽管网站在几个小时内无法访问，并且丢失了在备份之后产生的的很多数据，但最终还是恢复了绝大部分的数据，事件详情。
• WannaCry 病毒导致的数据丢失：WannaCry 是一种勒索病毒，针对 Windows 系统的一个漏洞去加密系统上的用户文件，导致用户无法访问这些文件，除非向一个比特币账户转账 $300 ~ $600（相当于几千人民币）。据报道有超过 30 万台电脑受到此病毒的感染。众多企业，包括银行、医院、铁路系统因病毒而无法正常运转。在中国，众多使用教育网的高校学生电脑受此病毒攻击，导致文件丢失。

以上的数据丢失都给人们带来了巨大的损失，但倘若我们能够提前做好数据备份，那么就能够降低数据后的损失。

最佳备份原则：321 原则

在进行备份的过程中，我们应该施行 321 原则，这样才能保证备份的可靠性与有效性。

• 三份数据拷贝：除了原始的数据之外，要另存两份数据的备份。倘若这三个拷贝丢失的概率相互独立（均为 1%），那么三份拷贝同时丢失的概率就仅有 0.0001% 了，这比两个拷贝同时丢失的概率更低。
• 两种存储介质：在同一种类型的存储介质上的数据更有可能同时丢失。比如你在电脑的内置存储器上存了三份数据拷贝，但如果电脑的磁盘彻底损坏、误格式化磁盘或者丢失了电脑，那么这些数据便一同丢失了。在上述案例中，另一种类型的存储介质可以是移动硬盘、SD 卡、U 盘、CD、DVD 等。
• 一个异地备份：多个备份间的物理隔离是很重要的。如果这些备份都放在一个房间里，那么一场火灾就足以毁掉所有的备份。如果条件允许，跨城市（间隔 100km 以上）存储备份就已经很安全了。在家和公司分别存放备份也算作异地备份。

此外也应该注意备份的时效性，如果可能，要尽量缩短备份周期。比如每分钟备份的时效性就强于每小时备份。在数据丢失时，前者只会丢失最近 1 分钟的工作，而后者会丢失最近 1 小时的工作。

云端备份

通常，云端备份是非常可靠的。云端服务器都会帮你做好 321 原则，你只需要选择一家云存储服务商并将要备份的文件上传上去即可。

建议选择提供了自动化备份功能的服务商，这样可以省去手动选择文件上传的步骤。通常自动备份还会对文件进行增量备份，即每次备份只上传上一次备份后有改动的文件，这样能大大节省上传时间。

一个典型的云端备份的例子是 iOS 中的 iCloud 备份功能，开启该功能后，iOS 设备会自动将图片、通讯录、文档、聊天记录、软件存档等个人数据上传到云端。在购买新的 iOS 设备后，这些数据都能够从云端自动恢复到新设备上。

使用对象存储进行简单的备份

定期将服务器上的重要文件打包上传到对象存储，即可实现简单的备份。可以直接使用 Amazon S3、Google Cloud Storage、阿里云 OSS、腾讯云 COS 的对象存储，上述服务均提供 99.999999999% 的持久性，即文件一旦上传完毕，几乎不可能意外丢失。云服务中的对象存储通常是在一个区域内的多个可用区（通常至少三个）进行存储，每个可用区内也包含文件的多个副本。各个可用区之间有一定的距离，所以这实现了异地。关于区域和可用区，可以详细参考 AWS 的这篇文章。

云服务的对象存储一般都可以选择地区。通常选择地理位置最近的地区以获得最低的延迟。这些服务通常是按照使用量计费的，主要包括在一定时间内占用的存储空间以及传输数据所用的流量费用。比如你要备份 1GB 的数据，那么每月可能只需要几块钱或几毛钱，甚至是免费的。（不同服务商收费不一）

很多服务器上的软件已经集成了使用对象存储进行备份的功能：在服务提供商开通了对象存储后，只需要在软件中配置好授权密钥，就可以使用对象存储进行备份了。如果软件没有集成这种备份功能，那么也可以手动实现简单的备份。比如，使用 mysqldump 导出数据库文件，使用 gzip 、 tar 命令压缩、打包要备份的文件。通常对象存储的提供商也有提供命令行工具，使用这些工具可以简单的将文件上传到对象存储中。如 AWS 有 aws，支持 S3 操作；Google Cloud Storage 有 gsutil；阿里云 OSS 有 ossutil；腾讯云有 tccli，支持 COS 操作。

使用快照对服务器进行全磁盘备份

通常快照可以备份服务器磁盘上的所有数据。从快照中恢复也十分方便。这甚至都不需要服务器上的软件支持备份功能。不管是服务器磁盘损坏、系统文件丢失，还是文件删除，都可以从快照中恢复。

如果条件允许，建议同时使用对象存储备份和快照备份。

本地备份

尽管云端备份简单、持久性高，但备份大容量的数据的速度与带宽成正比。何况备份所需要的是上行带宽，这通常是运营商所标称的下行带宽的几分之一。而仅仅是使用普通的机械硬盘进行备份，其速度就已经达到了千兆网络的速度，而千兆网络普及率低且价格极其昂贵。所以，遇到数据量大、带宽受限、备份/恢复时间有限等一种或几种情况时，本地备份也许更为合适。

在本地备份则需要自己做好 321 原则。你需要将数据备份到两个硬盘上（通过局域网或有线连接），并将其中一个硬盘存放在异地。很多桌面操作系统都支持了备份，你可以在最新的 Windows 系统的控制面板中找到备份功能，在 macOS 上使用时间机器（Time Machine）进行备份。建议配置好自动备份。

如果条件允许，建议在本地备份的同时，将较重要的文件再备份到云端。

历史版本的保留

我们应该保留文件的早期版本，以便不时之需。保留多个历史版本的文件使用增量备份有助于节省存储空间。如果条件允许，应保留尽可能多的历史版本。

早期的版本可以有相对更长的时间间隔，以便节省空间：像 macOS 中的时间机器（Time Machine），它会保留过去 24 小时的每小时备份、过去一个月内的每日备份、以及过去一个月以上的尽可能多的每周备份，直到磁盘空间填满。

一些网络存储会自动保留历史版本，比如 Dropbox、Google 云端磁盘、iCloud 等。一些软件也会在本地磁盘里保留历史版本。比如 Git 就会保留每一次提交的历史。

建议首先对重要文件保留历史版本，如果可能对所有文件保留历史版本。

其他

对象存储的存储类别（Storage Class）

通常对象存储提供多种存储类别，不同存储类别有不同的定价和使用场景，合理的使用多种存储类别可以节省支出。

Amazon S3 的主要存储类型

按存储价格由高到低排序，持久性均为 99.999999999%，均为多个可用区。

• STANDARD：默认，适合频繁访问的文件
• STANDARD_IA：存储单价更低（默认的 54%），但有额外的检索费用。此外，此类型至少存储 30 天，至少 128kb。
• GLACIER：存储单价最低（默认的 17%），不可实时访问，也有额外的检索费用

大于 128kb 的且不经常访问的备份建议存储到 STANDARD_IA，几乎不会再访问的早期的历史版本可以存储到 GLACIER。

Google Cloud Storage 的主要存储类型

按存储价格由高到低排序，持久性均为 99.999999999%，均为多个可用区。

• Multi-Regional：多地区存储（比多可用区更强），此存储类型会在一个洲内的多个城市/国家存放文件。按照官网说法上传后的文件会在至少间隔 160 公里的至少两个数据中心存储。适合存放在全球频繁访问的文件
• Regional：对应 S3 的 STANDARD
• Nearline：对应 S3 的 STANDARD_IA，是 Regional 价格的 50%，没有最低文件大小限制
• Coldline：对应 S3 的 GLACIER，且至少存储 90 天，但支持实时访问，是 Regional 价格的 35%，检索费用比 Nearline 更高。

同样的，不经常访问的备份建议存储到 Nearline，几乎不会再访问的早期的历史版本可以存储到 Coldline。

阿里云 OSS 的主要存储类型

按存储价格由高到低排序，持久性均为 99.999999999%，均为多个可用区。

• 标准型：对应 S3 的 STANDARD
• 低频访问型：对应 S3 的 STANDARD_IA，是标准型价格的 67%，至少存储 30 天，至少 64kb。
• 归档型：对应 S3 的 GLACIER，是标准型价格的 28%，至少 64kb。至少存储 60 天，检索费用比低频访问型更高。

同样的，不经常访问的备份建议存储到低频访问型，几乎不会再访问的早期的历史版本可以存储到归档型。