バックアップストレージの作成は面倒だ

バックアップストレージの作成は面倒だ

個人のストレージ

ストレージを作成して同期することは、常に何かがうまくいかず、意図した通りに機能せず、必要な時に動かないという活動の1つです。そこで、自分のマシンでできる限りこれを修正しようと決意しました。

ここ数ヶ月で、すべての有用なファイルをデバイス間で適切に同期するのに役立つだろうと期待していた多くの便利なLinuxの知識を学びました。特に、この知識を使って完全に無料でこれを実現したかったのです。自分が作成し所有しているだけの自分のファイルを見るためだけに、プロバイダーにこれ以上お金を払う気はありませんでした。Google Oneストレージで一度この間違いを犯し、二度と繰り返したくはありませんでした。

標準的な3-2-1バックアップ技術には馴染みがありましたが、それを実装しようとしたり、真剣に考えたりしたことはありませんでした。そこで、この時が来たのです。

馴染みのない方のために説明すると、3-2-1バックアップとは、ストレージが以下の状態であることを意味します：3つのコピー、2つの異なるストレージメディア、1つのオフサイトコピー。

私にとってそれは以下のことを意味しました：

1. 動作中のレイヤー
2. ハードドライブ
3. 何らかのクラウドプロバイダー

この記事では、これらの各レイヤーについて私が下した選択肢を詳細に説明します。多くの間違いを犯した可能性があることを前置きしておきます。これは単に私の個人的な道のりを共有するためのものであり、決して推奨するものではありません（誰も推奨しないでしょうが）。

私のレイヤー

1. 動作中のレイヤー

動作中のレイヤーの計画を始めたとき、理想的な世界は、私の2台のミニPCとラップトップを含むすべてのドライバー間で同期でき、さらにスマートフォンやタブレットから同じファイルにアクセスできることだと気づきました。

私は主に2つのワークステーションから作業します。私のメインドライバーであるX1 Minisforumと、自宅にいないときに使用するLenovoラップトップです。技術的には仕事用のコンピューターもありますが、ストレージの目的では完全に別のデータを持っているため、カウントしません。

これらのデバイスはすべて非常に異なる制約を持っているため、それらをどのように調整するかについていくつかの検討が必要でした。そこで私がたどり着いたのは次のとおりです。私のメインのMinisforumミニPCがファイルの真実の源となり、デイリードライバーとして機能します。ホームディレクトリにはSyncフォルダが含まれており、これがすべてのデバイス間で同期され、維持されるべきものです。

これは、常にオンになっているNASとして機能する私の2番目のミニPC、GMKtec M3にSyncthing経由で同期されます。私は主に他のデバイスからSSHまたはTailscale経由でこのミニPCにアクセスします。

そして最後に、ラップトップをSyncthing経由でSyncに同期します。残念ながら、私のラップトップはWindowsであり、Linuxをインストールするのが怠惰でした（それは将来のプロジェクトです）。そのため、Syncthingをインストールする手順は少し異なりましたが、うまく機能しているようです（Windowsであることを考えると、非常に驚きました）。

重要なのは、Syncthingはバックアップではないということです。これらの各デバイスはローカルにファイルのコピーを保持していますが、互いに同期するため、1つが破損して変更を他のデバイスにプッシュすると、他のデバイスも破損します。したがって、これは1つのレイヤーとしてカウントされます。これらのマシンはバックアップではありません。

Syncthingは非常によく機能しますが、一貫した同期が必要な場合はデバイスが頻繁にオンになっている必要があるという制約があります。

スマートフォンはまったく別の問題です。他のマシンにあるすべてのファイルを保存するのに十分なストレージがなく、たとえあったとしても、それがうまく機能するようになるには苦労するでしょう。私のSyncのサイズは実際にはかなり小さいです。わずか12GBですが、128GBのスマートフォンに収まるほど小さくはありません。残念ながら、アプリが多すぎます。

余談：12GBのコンテンツしか持っていないことで私を笑うかもしれませんが、私はミニマリストであり、実際に必要なものだけを保存するのが好きです。そして、このフォルダをかなり頻繁に管理するように努めています。

M3のホームフォルダには、もう使用しないファイルのログを保持するアーカイブフォルダがあります。

私が採用した解決策は、M3にTailscaleを設定し、TailscaleにiPhoneから接続し、Runestoneを使用してファイルがローカルに存在しない場合でもローカルで表示することでした。これの欠点は、ファイルにアクセスしたいときは常にTailscale接続が必要になることですが、それ以外は驚くほどうまく機能します。

当初、iOSのウォールガーデンのおかげで、Androidタブレットの方がバックアップの設定が簡単だと思っていました。しかし、それは間違いでした。私の必要な問題をすべて解決するRunestoneの同等物はありませんでした。そのため、醜悪で壊れやすい、狂ったような回避策を作成する必要がありました。しかし、今のところうまくいっています。

私がしなければならなかったことは、Tailscaleを設定し、それをTotal Commanderというアプリに接続することでした。これは単なるファイルリーダーです。次に、Tailscaleから来るローカルファイルにアクセスできるLAN用の拡張機能を取得しました。Total Commanderはファイルを読み取るためだけに、それを変更するために別のアプリを取得する必要がありました。多くのMarkdownリーダーを試しましたが、すべてひどかったので、Acodeに落ち着きましたが、より良い代替手段をすぐに見つけるでしょう。さらに、Total Commanderは新しいファイルを作成できないため、新しいファイルを作成したい場合に見つけた唯一の回避策は、既存のファイルのコピーを作成してそれを変更することです。これは非常に醜いことを理解しています。どうか判断しないでください。

これらすべてにおいて、私の結論は次のとおりです。Tailscaleは真の王様です。Syncthingは素晴らしいです。iOSは私が覚えているよりも良かったです。AndroidはWindowsとほぼ同じくらい悪くなりました。

2. ハードドライブ

このレイヤーは、単純なバックアップを保持できる静的なハードドライブです。

私はこれにresticを使用し、バックアップがタイムリーかつ効率的であることを確認したかったのですが、これはハードドライブに最適なファイルシステムについて私を深い穴に陥れました。私のハードドライブはデフォルトでFAT32になっており、12GBのデータを移動しているだけでNetflixライブラリ全体をバックアップしているかのように感じられました。いくつかの調査の後、Windowsとの簡単な互換性を維持したい場合、より優れたext4を使用できず、代わりにexFATにデフォルト設定する必要があることがわかりました。これはFAT32よりわずかに優れていましたが、ext4よりはるかに劣っていました。したがって、「Windowsはひどい」と何度も罵った後、私は諦め、exFATに移行することを受け入れました。さらに調査した結果、FAT32の利点は実際には私が気にかけているものではないことに気づいたので、怠惰になり、代わりにFAT32で進みました。

計画する次のステップは、バックアップを自動化する方法でした。resticの使用を勧められたので、試しました。それは、すべての情報を含む、圧縮され暗号化された素敵なフォルダを作成しました。そして、毎週日曜日の夜にSyncフォルダをバックアップするsystemdを設定しました。

resticは、バックアップのために存在する最高のものの1つです。それがしなければならないことに対して信じられないほどよく機能します。いくつかの欠点があります。たとえば、解凍に予想以上に時間がかかったことは期待していませんでしたが、おそらく多くの情報をそこに圧縮する必要があるのでしょう。12GBのデータを多くの重複排除により約6GBに減らすことができました。これは、すべてをローカルで行っている場合です。代わりに、ネットワーク経由でこれを行うと、3番目のレイヤーで見たように、少し不安定になる可能性があります。

3. 何らかのクラウドプロバイダー

これには多くの制約がありました。サブスクリプションを支払うつもりはないため、無料のストレージオプションでプレイする必要がありました。最も簡単なのはGoogle Driveのようでした。無料で15GBを取得でき、従来のバックアップ方法に接続するための優れた方法があります。

問題は、Google DriveがGmailとストレージを共有していることです。そのため、不要なメールを削除して十分なスペースを確保するという面倒な手順を踏む必要がありました。それが完了すると、10GB以上のストレージが残りました。これは、別のresticバックアップを行うのに十分でした。

写真は少しトリッキーでした。私は元々、サブスクリプションを支払うことに同意していた頃に、iPhoneの写真アプリからGoogleフォトに写真をバックアップしていました。移行するには時間がかかり、あまり有益ではなかったでしょう。なぜなら、結局バックアップ経由でコピーし直さなければならなかったからです。そこで、少し異なる解決策を選択しました。Sync内にPhotosという名前のフォルダを作成し、PhotoSyncを使用して残りを処理しました。これにより、同期された写真はGoogleフォトにも同期されました。そのため、Syncとは異なる方法で3-2-1カバレッジを引き続き得られると考えていました。仕組みは次のとおりです。

1. 動作中のレイヤーは、携帯電話経由でPhotoSyncを通じて写真を受け取ります。
2. HDDハードドライブの代わりに、ラップトップがサードストレージロケーションとして直接機能します。なぜなら、写真がローカルに存在するからです。
3. Google Driveは、restic経由でこれらをまだ保持しています。

うまくいけば、これで全部でした。

いいえ、まだ終わっていません。iOSとGoogleはひどく、私が自分のマシンや写真で行いたいことをさせてくれません。私が持っているフォルダはPhotoSyncと同期されていますが、PhotoSyncは自動転送を許可しません。私は写真にあまり興味がないので、修正に時間を費やすことはしません。そのため、現在は次の恐ろしいセットアップになっています。

1. 写真アプリには、最も最近の情報がすべて含まれています。
2. 時間があるときに、PhotoSyncを使用して、コンピューターにローカルにない写真を手動で転送します。手動ですが、この部分は驚くほどスムーズでした。無料の自動方法がないのは非常に愚かです。
3. 次に、このiPhoneフォルダはSync内にあり、HDDとGoogle Driveに自動的に伝播します。これは、Google Driveが技術的に画像を2回持っていることを意味します。1つはGoogleフォト経由で、もう1つはiPhoneフォルダを同期することによるものですが、十分なスペースがあるので問題ありません。
4. これは好きですか？いいえ。もっと満足のいく選択肢はいくつかありますが、時間をかけて更新する価値がないという点に来ると思います。だから、今のところそのままにしておきます。

次に、Google DriveをM3にマウントし、resticを使用して同期しようとしました。もちろん、これもスムーズではありませんでした。非常に遅かったですが、最終的には進歩し始めました。リクエストが多すぎたり、HTTPレイテンシのために何度も停止したため、Syncのサブフォルダにバックアップリクエストを分割する必要がありました。それも遅すぎたので、Google Driveでのresticの使用をあきらめ、本当に単純化することにしました。デイリードライバーからSyncフォルダをzip圧縮し、rclone Google Driveインスタンス経由でコピーしました。非常に醜いですが、少なくともオフサイトコピーがあります。そして、復元したいときはいつでも、この手順をやり直すだけで、resticが私に引き起こしていた何時間もの苦痛ではなく、数分しかかかりません。

Google Driveとの同期を自動化することさえしませんでした。なぜなら、私は非常にイライラしており、すべてが非常に壊れやすかったからです。手動で行うことにします。それで十分です。オフサイトコピーを使用する必要がある状況になった場合、数週間の作業を失うことは私の問題の最小限になるでしょう。最初のアップロード後は、resticが同一のファイルをより迅速に処理するため、アップロードが改善されるはずですが、現時点ではその証拠はありません。

その他のバックアップ資料

この時点で、Syncはほぼ成功していたか、少なくとも満足できるレベルに達しており、残りのいくつかのレイヤーのバックアップに進む時間でした。

リストのトップにはdotfilesがありました。設定は非常に重要です。なぜなら、私はそれらにかなりの時間を費やしてきたので、その進歩をすべて失いたくないからです（ああ、neovimの設定を書き直すことは想像できません）。いくつかの調査の後、chezmoi（フランス語を知っていますが、最初は名前が何かわかりませんでした）が最も人気のあるオプションの1つであることがわかりました。簡単なセットアップの後、その理由を理解しました。非常にシンプルでありながら効果的でした。すべてをGitHubにプッシュして、それで終わりとしました。

適切にバックアップする方法を理解できなかった他の資料の1つは、メールです。理由は、体系的にバックアップする明確な方法がなく、Google Driveにアップロードされるのを避けるためにSyncに入れたくないからです。これについては後で戻る必要がありますが、それはすぐにはありません。

最後に、OSの状態を回復できるようにしたかったのです。このマシンはArchを実行しており、まだ発生していませんが、新しいアップデートが問題を発生させる可能性があることを常に受け入れる必要があります。したがって、安定した状態にロールバックする計画があることは役立つかもしれません。これのためにTimeshiftをインストールして設定しましたが、基本的な設定以外ではあまりいじっていません。Archが壊れるまで、おそらくそれについて意見を持つことはないでしょう。

さようならとAI開示

この手順全体を通して、非常にうまく機能したものと、妥協したり完全に諦めたりしなければならなかったものがありました。これは、他の種類のテクノロジーであっても、私の平均的な結果のように感じられます。

これらの多くは、現時点では非常に安定しているように見えます。他のものは非常に壊れやすいように見えます。したがって、これは私のシステムをバックアップする上での最初で最後の投稿になるか、長いシリーズのパート1になるかのどちらかです。時が経てばわかるでしょう。

この投稿で最も頻繁に使用された単語は「suck」（およびその活用形「sucks」と「sucked」）であり、この投稿をよく要約しています。

参考までに、このバックアップの設計上の選択や、これらのセットアップの技術的な実装の一部をナビゲートするために、AIを広範囲に使用しました。この執筆にはAIは使用されていません。そのため、文章が機械のように聞こえると思うなら、私の文章がひどいからだと安心してください。