バックアップちゃんとできていますか?

Summary ¶

バックアップについて手法を確認し弊宅でのバックアップポリシーは 3-2-1 手法にすることにした

そのうちの２つはローカル環境の別々のメディアに保存します
- 1: 内蔵 HDD
- 2: 別電源の外付け HDD
もう 1つはリモートやオフサイト(物理的に切り離して)保管する
- 3: クラウドストレージに暗号化して転送する

ランサムウェア対策と利便性向上のため ZFS Snapshot を活用する
ZFS Snapshot は SMB 共有時に「以前のバージョン」で容易に参照でき、書き込み禁止領域のためランサムウェアなどの侵害を受けづらい、このデータを外付け HDD に Local Replication することでローカルの2つ目のバックアップとする

Snapshot 取得間隔は Time Maschine などと同様に下記とするが容量の都合があるため期間で削除する

項目	Snapshot Lifetime
15 Minutely	1時間
Hourly	3日間
Daily	35日間
Weekly	5週間
Monthly	5ヶ月
Quarterly	14ヶ月

S3 等で Versioning lifecycle が定義できる場合過去のバージョンは3バージョン保持か14日で削除する

バックアップとは? ¶

弊宅では、◯◯回のインシデントを起こしておりオンラインシステムにデータが保管されていたためデータロストはほとんど免れたが一部の編集中及び作業中のデータはロストする重大インシデントが発生している。
(1.2TBのデータプールで発生し 1TBが即時データロストオンラインから復旧に15日、200GB作業中で手元から再開、10日の作業は水の泡)

さて、まとめようと思ったきっかけとエグさを共有した所で本題に入ろう。

世の中で言われるバックアップ手法に 3-2-1 バックアップという考え方がある

データのコピーを 3つ用意する
そのうちの２つはローカル環境の別々のメディアに保存します
もう 1つはリモートやオフサイト(物理的に切り離して)保管する

これらをもう少し詳細に書いていく

1. データのコピーを3つ用意する ¶

これは、結果的に下の2つを満たすとデータの完全コピーが3つあることになる。そしてこの方法を取ると2つはホットデータ、1つはオフサイトか改変不可な状態のデータとなり安全性が高い状況が作れる。

2. そのうちの２つはローカル環境の別々のメディアに保存 ¶

ローカルの2つの物理的な筐体に保管することで電気的、物理的破損に対応したいというのがこの趣旨である。「別々のメディア」と言うのはよく誤解されるが RAID をして物理的に書き込む Disk を分けるということではない。なぜなら筐体が一緒なら電源、ソフトウェア、ハードウェアは大部分が共通のため少なからず影響を受ける可能性が高い。
(弊宅のデータロストもソフトウェアによる問題であった)

そのため、物理的に2つの筐体を用意しデータを同期(Replication)するのがこの趣旨である。一般的にはこの環境を用意するのが厳しいため最初に用意した筐体をリプレースする時に計画することがほとんどではないかと思う。弊宅の場合も例外ではなく古い NAS があるがハードウェア的にストレージ容量が足りなかったり 1Gbps x2 しかない筐体のため 3.5inch HDD を外部電源のエンクロージャで接続している。こうすることで物理的破損とソフトウェア障害はおそらく回避できると想定している。

3. もう1つはリモートやオフサイト(物理的に切り離して)保管する ¶

2. そのうちの２つはローカル環境の別々のメディアに保存 の対策では、ローカルでの物理的、ハードウェア、ソフトウェアのリスク対策としてローカルで2つの筐体に複製を用意することを提唱しているが。わが国を含め近年では自然災害が多く特に家庭内インフラの面では下記に注意する必要がある。

落雷などによる停電、サージ電流による物理的損傷
自宅メンテナンスなどでの落下物や筐体の物理落下
設置場所への物理アクセスでの破壊や持ち去り
地震、洪水などによる物理破損

これらへの対策としてリモートへのバックアップが必要である

Note

データは唯一無二の物が多く、現代社会ではロストすると再入手に非常に多くの時間と労力が必要になる場合が多いこれは今後も変わることはおそらくなく、ローカルにあるハードウェアにはおそらくつきまとう問題

クラウドバックアップと一言で言っても様々な方法があり、コストの問題は切っても切り離せないと思います。
また、児童ポルノや青少年に関する対応で子供の写真などをクラウドサービスに預けていたらいつの間にかに削除されている場合や最悪アカウントごと Ban され二度とアクセスできなくなるという場合もあるようです。

そのためクラウドにバックアップする場合は必ず暗号化して転送しておくべきだと考えています。
プライバシーの問題もあるのでクラウドサービス側の設定ミスなどでファイルが世界に公開される状態やクラウドサービス側から中身を覗き見られるのはいい気分では無いですしね…

S3 Compatibility とは? ¶

Amazon S3 というオブジェクト指向型ストレージサービスが存在しており、従来では Linux などに filesystem を作成して保存する関係で最大容量が決まっているし階層構造が必要で超大容量(1PBれべるなど)では大変だった

また、複数の filesystem を作成する都合上莫大なコストもかかり大変な思いをして運用されていた。が Amazon が初めての初めてビジネスとしてサービスし始めたのが Amazon S3 であるこれは 2006年に始まった Amazon 最初のサービスとして有名だろう。

上記のサービスが始まってからオブジェクトストレージが認知されて Amazon S3 と同等の API で利用できるストレージが次々に開発されていった。そのためそれをユーザーに説明する時 Amazon S3 と同じように使えますよ, ということで「S3 Compatibility (S3互換)」というようになった。

何と言っても、普通にストレージを買うより安い点が最大のメリットで状況にもよるが保管だけにフォーカスを当てると $0.005/GB 程度になる 1TB の容量が $5/月程度で利用できるのでバックアップとして使わない手はない

Periodic Snapshot Tasks ¶

項目	Snapshot Lifetime
15 Minutely	1時間
Hourly	3日間
Daily	35日間
Weekly	5週間
Monthly	5ヶ月
Quarterly	14ヶ月

少し気になったのは、公式ドキュメントには下記記載がある
これを簡単ではあるが動作確認しておきたい。

Setting Snapshot Lifetimes ¶
TrueNAS deletes snapshots when they reach the end of their life and preserves snapshots when at least one periodic task requires it. For example, you have two schedules created where one schedule takes a snapshot every hour and keeps them for a week, and the other takes a snapshot every day and keeps them for 3 years. Each has an hourly snapshot taken. After a week, snapshots created at 01.00 through 23.00 get deleted, but you keep snapshots timed at 00.00 because they are necessary for the second periodic task. These snapshots get destroyed at the end of 3 years.
TrueNAS は、スナップショットの寿命が尽きるとスナップショットを削除し、少なくとも 1 つの定期的なタスクでスナップショットの保存が必要な場合はスナップショットを保存します。たとえば、2 つのスケジュールを作成し、1 つのスケジュールは 1 時間ごとにスナップショットを取り、1 週間保存し、もう 1 つのスケジュールは毎日スナップショットを取り、3 年間保存します。それぞれ1時間ごとにスナップショットが作成されます。1週間後、01:00から23:00に作成されたスナップショットは削除されますが、00:00に作成されたスナップショットは2つ目の定期的なタスクに必要なので残しておきます。これらのスナップショットは3年後に破棄されます。
― Adding Periodic Snapshot Tasks |

動作確認方法として下記を設定したすべて同じ Naming Schema にすることで不要になったスナップショットが自動で消される想定である。そのテストを簡単に実施して問題なく、動いているのを確認した。

項目	期限(時間)	Snapshot 数
6Minutely	1時間	12
10Minutely	3時間	18
30Minutely	5時間	10

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
## list
root@truenas[~]# date
Thu Dec 14 23:37:07 JST 2023
root@truenas[~]# zfs list -t snapshot -o name DataVol1
NAME                              6Minutely    10Minutely    30Minutely
DataVol1@auto-2023-12-14_19-00                               9
DataVol1@auto-2023-12-14_19-30                               8
DataVol1@auto-2023-12-14_20-00                               7
DataVol1@auto-2023-12-14_20-30                19
DataVol1@auto-2023-12-14_20-40                18
DataVol1@auto-2023-12-14_20-50                17
DataVol1@auto-2023-12-14_21-00                16             6
DataVol1@auto-2023-12-14_21-10                15
DataVol1@auto-2023-12-14_21-20                14
DataVol1@auto-2023-12-14_21-30                13             5
DataVol1@auto-2023-12-14_21-40                12
DataVol1@auto-2023-12-14_21-50                11
DataVol1@auto-2023-12-14_22-00                10             4
DataVol1@auto-2023-12-14_22-10                 9
DataVol1@auto-2023-12-14_22-20                 8
DataVol1@auto-2023-12-14_22-30    11           7             3
DataVol1@auto-2023-12-14_22-36    10
DataVol1@auto-2023-12-14_22-40                 6
DataVol1@auto-2023-12-14_22-42    9
DataVol1@auto-2023-12-14_22-48    8
DataVol1@auto-2023-12-14_22-50                 5
DataVol1@auto-2023-12-14_22-54    7
DataVol1@auto-2023-12-14_23-00                 4             2
DataVol1@auto-2023-12-14_23-06    6
DataVol1@auto-2023-12-14_23-10                 3
DataVol1@auto-2023-12-14_23-12    5
DataVol1@auto-2023-12-14_23-18    4
DataVol1@auto-2023-12-14_23-20                 2
DataVol1@auto-2023-12-14_23-24    3
DataVol1@auto-2023-12-14_23-30    2            1             1
DataVol1@auto-2023-12-14_23-36    1
root@truenas[~]# 

## destory
zfs list -t snapshot -o name | xargs -I'{}' zfs destroy '{}'