Anu*_*air 1 linux archiving amazon-glacier
背景： 一个内容制作团队以数字媒体格式拍摄和记录内容。这些可以是原始素材、转换后的视频和图像的混合。
这些内容存储在一个共享文件夹（Linux Samba）中，它是 21 TB 的存储空间，几乎已被完全使用。我更愿意让这些内容团队重新组织和清除数据。忽略纪律的需要，我被要求简单地存档。这是有道理的——随着岁月的流逝，无论保持多少纪律，磁盘空间都会变薄。
我们曾在旧领导下使用磁带驱动器进行归档。新的领导层已经停止了这个过程。他们建议将旧内容存档到 Amazon Glacier。
现在，作为存档，内容大小可能约为 2Tb。可能需要拉出旧内容。多频繁？--我们现在还不知道。
无论亚马逊可以提供多少带宽，我所拥有的线最多可以达到 40 mbit/s。此外，我被要求通过某种方式限制速度，以便同一 Internet 连接上的其他人不受传输的影响。
什么都考虑，我应该采取到帐户在冰川上是否适合这种任务的法案的理解到达。
另外，是否有任何 BASH 命令行工具可以将2 Tb+ 档案推送到 Glacier Vault ？
Glacier 是为您预计可能不需要的数据而设计和定价的。
Glacier 的设计预期检索是不频繁和不寻常的，并且数据将被存储很长时间。
我现在有几十 TB 存储在那里，我强烈推荐它——在适当的情况下——所以我的观察不应该被视为消极的，只是强调你需要确保你了解产品及其预期应用。
原生 Glacier 界面非常低级。它的行为有点像备份磁带或大 tarball。您将“档案”放入“保险库”中，它就像一个黑匣子。您必须保留在每个存档中放入的内容的记录，因为 Glacier 无法告诉您，就像物理上查看备份磁带可以告诉您的一样。
另一种——我会断言——使用 Glacier 更好的方法是通过 S3。将您的文件上传到 S3 存储桶，并设置存储桶的生命周期策略，几天后将文件存档到 Glacier。使用此模型，S3 隐藏了原始 Glacier API 的复杂性，并且单个文件及其元数据通过 S3 控制台和 API 保持可见。费用是一样的。
但是，请理解，使用 Glacier（无论是否通过 S3），您需要为一次恢复多于少量数据支付费用。
仔细分析这些数字，您会发现在您存储大量数据之前，恢复的免费限额可能很昂贵。
假设我存储了 180 TB/180000 GB。如果我不想为数据检索支付额外费用，我只能在任何 4 小时窗口中恢复 50 GB。
180000 × 0.05 ÷ 30 ÷ 6 = 50
180000 GB，每月 5% 的津贴，30 天/否，每天 6 次 4 小时。这对我很有用，因为我的文件通常小于 20 GB，而且我很少需要它们。当我这样做时，通常用于不紧迫的研究，以便我可以分散恢复。如果总存储较小，比如 18 TB，我的免费恢复限额将是每 4 小时 5 GB。因此，正如我所说，请仔细考虑恢复定价模型。
S3 提供的相对较新的“不频繁访问”存储类可能更适合。0.0125 美元/GB/月仍然相当合理，虽然下载费用为 0.01 美元/GB，但如果您需要恢复大量数据，成本不会急剧增加，并且没有 4 小时的等待时间，就像冰川一样恢复。
| 归档时间： |
|
| 查看次数： |
236 次 |
| 最近记录： |