1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

35世代保持する設定のRDSスナップショットが60個あった件

Posted at

RDSを設定していて、バックアップとしてスナップショットを35世代保持する設定をしていました。
数ヶ月経ってスナップショットを確認すると、なんと35個ではなく60個以上作成されていました。

この件について、調べてわかったことをまとめます。

対象RDSについて

    1. エンジンはPostgreSQL
    1. シングルAZ構成(冗長化なし)
    1. ランニングコスト削減のため夜間帯(21:00-07:00)は停止している

スナップショットがやたら多い

image.png

35世代分取得するはずなのに、なぜか62個スナップショットがあります。
なぜでしょうか。。。

少し調べてみた

Q: 自動化された DB スナップショットの数が、DB インスタンスに対するリテンション期間の日数よりも多いのはなぜですか?

リテンション期間の日数よりも 1 日か 2 日自動化 DB のスナップショットの日数が多いのは正常です。自動化スナップショットは 1 日余計にとられていて、リテンション期間中のいつにでも復帰できる時点を設けています。例えば、バックアップウィンドウが 1 日に設定されている場合、自動化スナップショットは 2 つ必要で、これで過去 24 時間中の任意の時点への復帰をサポートしています。また、さらに多くの自動化スナップショットがある場合もありますが、これは新たな自動化スナップショットが、最も古い自動化スナップショットを削除する前に常に生成されるためです。。

1/2日分のスナップショットが余分に保持されているのは正常な動作と書かれていますが、35世代に対して60個は明らかに多すぎます。なので別の原因があると想定します。

さらに調べてみた

DB インスタンスの停止中は、自動バックアップは作成されません。
DB インスタンスが停止している場合、バックアップ保持期間より
長くバックアップを保持できます。RDSには、バックアップ保存期間の
計算時にstopped状態にあった時間は含まれません。

つまり
保持日数の設定は日にち単位でのカウントではなく、時間単位の計算となっている
というわけです。

これがどういうことかというと、例えば
10日分保存する設定にしていれば、24 x 10 = 240時間分のバックアップ(スナップショット)を保持する事になる。RDSが停止している時はこの時間にカウントされない。もし夜間停止などを行なっているRDSがあり1日に12時間起動する場合、240 / 12 = 20世代のバックアップが取得される。
ということになります。

今回、RDSは21:00-07:00にて夜間停止を行なっています。つまり一日あたりの起動時間は14時間です。
一日あたり14時間起動するRDSのスナップショットを35日分取得するとなると、

35 x 14/24 = 60

辻褄が合いそうですね。

まとめ

RDSのスナップショットにおいて、
保持期間は日にち単位ではなく時間単位の計算となる(保持期間 ≠ 保持世代)

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?