Day 18 储存宝石：【Lab】S3 储存类别 & 生命周期管理 (下)

今天，我们要来示范如何去还原存在 Glacier 里头的档案，并观察整个过程所需的时程。

Glacier 类别的取用与 Restore 实作

假设想要回复这个变成 Glacier 类别的档案，就可勾选档案(下图#1)，点开 Actions 选单(下图#2)，再按下 Restore (下图#3)开启 Restore 介面。

所谓的 Restore，并非把档案从 Glacier 类别移回来，事实上，是去跟 Glacier 做一个暂时的 Copy，把档案 Copy 一份到 S3 service 上面，来让我们可以去下载，所以档案实际的存在位置还是在 Glacier 那边。了解 Restore 的概念後，接下来进行细部设定。

首先，这次要取回的档案只有 1 个，Total size 是档案大小的呈现(下图#1)，输入栏可输入档案取回後，在 S3 介面上存放的天数(下图#2)，Restore tier 则是根据我们可以等待的取用时间来决定(下图#3)。

Restore tier 总共有 3 个选项可以决定，Bulk retrieval 是等待 5 至 12 小时，为最便宜的取用费用(下图#1)；Standard retrieval 是 3 至 5 个小时，为一般取用费用(下图#2)；Expedited retrieval 是 1 到 5 分钟，为最高的取用费用(下图#3)。

照理来讲，当我们决定已经把一个档案放到 Glacier，基本上就是已经准备好要等 3 到 5 小时的时间了(下图#2)，但是如果有意外的话，就可以选择最後一个 Expedited retrieval (下图#3)，1 至 5 分钟便可以取回，但费用会非常的贵，如此就会与当初将档案放到 Glacier 的动机产生冲突，所以基本上还是不会选择 Expedited retrieval (下图#3)，所以这次实作会选择 Standard retrieval (下图#2)，按下Restore来完成设定(下图#4)。

在等待Restore的漫长时间中，则继续往下进行另一部份的实作示范。

Lifecycle 的实作

在 S3 Bucket 阶层，点开 Upload 介面(下图#1)，按下 Add files (下图#2)浏览档案。

选择要上传的档案(下图#1)，点击右下 Open (下图#2)。

确认要上传的档案在列表上後(下图#1)，点击 Upload (下图#2)。档案上传完毕後，再点进档案页(下图#3)。

在 Bucket 层级下，切换至 Management (下图#1)，选择 Lifecycle (下图#2)，点击 Add lifecycle rule (下图#3)，开启 Lifecycle rule 介面。

在 Lifecycle rule 介面中建立名称(下图#1)，选择套用到所有的 Object 上(下图#2)，再来点击 Next (下图#3)进到下一步。

Storage class transition 功能，可以选择套用到过去的版本，不过这边套用到现有版本就好了(下图#1)。
接下来，点击 Add transition (下图#2)，选择想移动到的 Storage class，而这边先假设选 Standard-IA (下图#3)，会看到右边有天数设定，试着将 30 改为 10 (下图#4)，会出现警示讯息，表示想成功套用 Lifecycle rule 的话 ，最少要等待 30 天以上，也就是档案上传 30 天之後，才能把档案移过去，所以还是遵照规则，设为 30 天。

而为了能省比较多钱，再改选为移动到 One Zone-IA (下图#1)，点击右下 Next (下图#2)进到下一步。

进入到 Expiration 功能介面，可以选择套用到现有的版本上，不过这里则选择套用到之前的版本上(下图#1)。

Expiration 功能还可以根据团队的需求把特定期限前的版本给 Expire 掉(下图#2)，例如设定不需要保留 365 天前的版本，Expiration 就会将 365 天前的版本给 Expire，设定完再点击 Next (下图#3)进到下一步的 Review。

进到 Review 後，勾选并同意套用到所有的 Object 上(下图#1)，点击 Save (下图#2)来储存 Lifecycle rule 的设定。

到此，便完成了 Lifecycle rule 的设定。以後在此 Bucket 上的档案，过了 30 天之後，都会被移到 One Zone-IA，并且这个 Bucket 上面所有的旧版本，都会在 365 天之後被 Expire，并且被 Expire 的档案也会被清除掉，如下图：

再从 Glacier Restore 执行并等待 5 小时後(下图#1)，切回 Overview (下图#2)，点进先前被 Restore 的档案页面(下图#3)。

在被 Restore 的档案页面上，发现原本不能使用的 Download 可以点击了(下图#1)，把档案下载开启，就可以看到当初存进 Glacier 之前的档案内容拿回来了(下图#2)。

由於先前在 Restore 的档案保留天数是设定为 7 天，也就是说假设今日为 8/13 (下图#1)，加上 7 天，档案就会保留到 8/20，就如同 Restoration expiry date (下图#2)所显示的日期，时间到了，就会把此档案 Expire，最後就会从 S3 服务上清空。

结语

本文透过储存类别间的移动，又以 Restore 尝试对 Glacier 类别做取用，而在等待 Restore 的时间中，更进行了 Lifecycle 的实作，为档案设置了生命周期管理，使能够自动清除特定期间的档案，以降低储存成本。

在 Restore 取用资料的五个小时过去以後，成功地再次於 S3 服务上利用被移动到 Glacier 的档案，而经由设定的档案保留时间，再度地感受到档案在Storage class 移动分配上的巧妙之处。

那以上，即是我们今天 AWS S3 储存类别与生命周期管理的实作示范。

What's Next?

到了今天，我们也用了 5 天来深入了解 S3 的各种储存类别、生命周期与版本特性，还有着更多值得动手做的 Lab，像是 S3 Versioning 等，但我们也该前往第四个「资料宝石：RDS是什麽？RDS vs EC2 (+db) 方案比较」！