ZFS と zrepl を使用した災害復旧

(最初に共有されたのは マストドン)

先週、私は簡単な電子メールを送信するためにラップトップを開けました。 黒い画面が固まってしまったので、再起動してみたら… ああ、しまった。

2 年前に使用した SSD が突然故障してしまいました。 これはガッツパンチだったが、エースを決めた。 私はこれを、復元したシステムの新しいドライブから入力しています。

合計で約 10 分間のデータが失われました。 その方法は次のとおりです。

zrepl を使用したデータの保存

私はドライブをバックアップするのではなく、複製します。

昨年の冬、私は初めて本格的なホーム ネットワーク ストレージをセットアップしました。 このプロジェクトの一環として、クリエイティブな作業を行うコンピューターの定期的なバックアップを設定することが含まれていました。 オプションを調査した結果、ZFS 増分レプリケーションという 1 つのアプローチが際立ったことがわかりました。

ZFS の主な機能の 1 つは、実行中に効率的なポイントインタイムのスナップショットを取得できる機能です。 その後、 かわった データを他のマシンに転送します。

スナップショットの取得と NAS への送信を自動化するために、私は という非常に優れたソフトウェアを使用しています。 補充 （による @問題）。 ファイルシステム全体のスナップショットを 10 分ごとに送信するように設定しました。

スナップショットは増分であるため、レプリカを最新の状態に保つためにホーム ネットワークのバックグラウンドで実行しても問題ありません。 最後の実行では転送に 14 秒かかり、約 64 MiB が送信されました。

ZFS スナップショットからの復元

システムの復元は学習プロセスであり、残念ながら完全に手作業でした。 625 GiB ZFS 受信操作を一晩実行させました。

私のスナップショットは元のコンピューターによって暗号化されています (NAS はスナップショットを読み取ることができないため、これは素晴らしいことです!)。 したがって、バックアップを使用できるようにするために、暗号化の「ラッパー キー」も復元する必要がありました。

最初にキーをロードしようとしたとき、復号化に失敗し、お腹が落ちました。 予定があるとき しないでください 作業中に、すべてのプロセスの失敗が明らかに明らかになる瞬間があります。 ありがたいことに、出力をよく観察したところ、間違ったシステムのキー ファイルをコピーしていました。 すぐに、データを復号化できることが確認されました。 とても幸せな瞬間です！

システムを再構築するために、次に従いました Ubuntu 22.04 ルート ファイルシステムを最初からセットアップするための OpenZFS ガイド ライブUSB経由。

これは、復旧して実行するための貴重なリソースでした。 昔は怖かったけど、今は それで このプロセスを通じて私はたくさんのことを学びました。 これは、Debian 環境における最新のパーティショニングと chrooting について、私がこれまでに見た中で最高の実践ガイドです。

最終結果は素晴らしい瞬間でした。私のラップトップは、放置していた場所に戻って起動しました。 ブラウザのタブでも、前夜の未完了の作業が復元されました。

騒乱の計画

12 年前の Chromebook 広告の古典的なシリーズがあります。 コンピューターは手の込んだ方法で繰り返し破壊される。 毎回、ホストは新しいラップトップを入手し、データを失うことなく中断したところから再開します。

その広告は10年以上私の想像の中にありました。 私も同様の災害復旧計画を立てるという夢をついに実現しました。 そしてそれはうまくいきました！

ZFS のセットアップには、当初非常に高い開始コストがかかりました。ファイルシステム全体の交換が必要でした。 それを維持するには、かなりの知識と手作業のプロセスが必要です。 しかし、ユニークな利点があることは確かです。

15年以上SSDを使ってきましたが、思い出せる限りSSDを紛失したのはこれが初めてです。 最初のレプリケーションが失敗する前にレプリケーションを設定できたのは本当に幸運でした。 😇

ご興味があれば、問題のドライブは、最初に注文したフレームワークの WD_BLACK SN850 でした。 フレームワーク フォーラムで、このドライブが自然に停止したり起動できなくなったりするという不安な話を聞いていました。 どうやら私が不吉な数字を振る番だったようだ。