今天，我們要來示範如何去還原存在 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) 方案比較」！