棚田式非破壊型DASはNASを超えるぞ！

imakat — Thu, 22 Jan 2026 13:52:04 +0000

ブログの記事のネタが無くて困ることはよくあるでしょうが、今回のこのテーマは、全く逆で、ネタが多過ぎて、どこから話していいか見当もつかない様な面白いテーマです。まあ超マニアックですが。。いいえ核心かも。では話を始めます。

〜Mac miniによるDAS操作、Mac miniは今こそ本領発揮の時代に入った〜

SynologyNASとMac miniを組み合わせたファイル管理システムを使い始めた頃から、「NAS自体がPCの機能を持っているので、Mac miniと機能が重複している。Mac miniの頭脳(OS)を使って、複数のHDDを、RAIDのようにガチガチではなく、もっと自由に扱うことができないか」と問題意識を持っていました。その解決策を提案しているYouTube動画が気になっていました。👉「NASじゃなくてもいいかも！Mac miniでデータ管理してみた(ギズモード網藤さん)」「【NAS＆RAIDより安全】２０２５年版　個人限定　データを守る方法を紹介　HDDケース」

棚田式を思いついたのは、ギズモードの網藤さんが「一年に１回、写真や動画を移動させるルールを実行している」と語っていたことがヒントになり、「棚田は許容量を超えたら水が溢れ出る→だが、ここで→古い水から下段へ移動できたら面白い」とイメージしたことです。
まずは動画をご覧ください。

👉低画質・枠外字幕はこちら

Warning: file_get_contents(https://imakat.com/gd_proxy/?f=videoct.json): Failed to open stream: HTTP request failed! HTTP/1.1 429 Too Many Requests in /home/imakat/imakat.com/public_html/wp-content/themes/cocoon-child-master/dr52emd.php on line 32

ポイント解説

（１）脱RAID(DAS)のメリット・デメリット

メリット

1. 異種混合ドライブの柔軟な活用（ハードウェア制約の撤廃）

サイズ違いの混在が可能:
手元にある4TBのHDD、8TBのHDD、1TBのSSDといった、容量や規格がバラバラのドライブを自由に組み合わせることができます。これらを「T1（保管段）」「T2（長期保管段）」といった論理的な階層（棚田）に割り当てることで、一つの大きなストレージプールとして扱えます。

コスト効率の最大化:
高騰する大容量HDDを新たにペアで購入する必要がなく、余っているドライブや安価に入手できた単体のドライブを即座に戦力として投入できるため、経済的です。

「処理ID」による独立したエコシステムの形成:
tanada.csvにおける「処理ID（例：T0001）」は、それぞれが独立したエコシステムを定義します。このシステムは常設する必要はありません。展示会の仮設システム用にHDDをかき集めたい、などという時にも使えます。

2. 「資産の流動性」と安全な転用（HDDのレゴブロック化）

設定ひとつでHDDを空にする:
例えば、T2（長期保管段）で使用している8TBのHDDを別のPCへ転用したい場合、Google Sheetsの設定（tanada.csv）でT2の容量制限を「0.0TB」に変更するだけです。

自動かつ安全な退避:
容量を0に設定してシミュレーションを実行すると、システムは「T2にはファイルを置けない」と判断し、T2内の全データを自動的に上位のT1（または他の空き領域）へ移動（逆流）させる「完璧な計画書」を作成します。

物理作業の簡素化:
承認ボタンを押して自動移動（Apply）が完了すれば、HDDは空っぽになるため、安心して取り外して転用できます。

単体での可読性(プラグアンドプレイが出来る):
NASやRAIDのアレイ（RAID 5など）に組み込まれたHDDは、1本だけ引き抜いて他のPCにUSB接続してもデータを読み出せません。しかし、このシステムのDAS構成では各HDDが独立した標準フォーマット（APFSやexFAT等）でフォーマットされているため、USBケーブルを抜いて別のPCに挿す（プラグアンドプレイ）だけで、即座に普通のHDDとしてデータを読み書きできます。

3. 復旧プロセスの単純化（ボリュームリネームによる復旧）

シンプルなミラーリング:
各段位（T0, T1…）に対して「main」と「mirror」というボリュームを用意し、FreeFileSyncなどの一般的なアプリで毎日コピーを作成できます。

ボリューム名の変更で復旧:
もし「T0_main」のディスクが故障した場合、バックアップである「T0_mirror」のボリューム名を「T0_main」に変更するだけで、システムは何事もなかったかのように稼働を再開できます。これはRAIDのリビルド待ち時間や専門知識を必要としない、極めて直感的な復旧方法です。

4. 検索・閲覧の単純化:

巨大なフォルダ（例：「写真」）が、容量の都合で物理的にはT1とT2の2つのディスクに分断されて保存されていたとしても、ファイルパス（ディレクトリ構造）が完全に維持されているため、それらを重ね合わせて「一つの巨大な写真フォルダ」として閲覧することが容易です。

5. 事故を防ぐ「判断」と「実行」の分離:

非破壊シミュレーション:
実際のファイルを動かす前に、メタデータ上で移動計画を立てます。もし容量不足や設定ミスがあっても、実データは一切変更されていないため、何度でも設定をやり直すことができます。

意図せぬ消失の防止:
システムは承認された計画（Apply Plan DB）にある移動（MOVE）のみを愚直に実行し、計画にないファイルには一切触れないため、手作業のファイル整理で起こりがちな「誤って消去した」「どこへ行ったか分からない」という事故を原理的に防ぎます。

デメリット

1. 「可用性」の低下（ダウンタイムの発生）

復旧には手動介入が必要:
本システムでは、各段位（T0, T1…）に対して「main」と「mirror」という独立したボリュームを作成し、同期アプリでコピーを取る運用が想定されています。もし「main」が故障した場合、RAIDのように自動で切り替わるのではなく、ユーザーが「mirror」のボリューム名を「main」に書き換える（リネームする）という復旧作業を行うまで、システムは停止します。

リアルタイム同期ではない:
常時同期するRAIDと異なり、FreeFileSyncなどで「毎日1回コピー」する運用の場合、故障したタイミングによっては、前回バックアップ以降のデータ（最大1日分）が失われる可能性があります。これを防ぐために**「作業は原則T0（Dropbox等）で行う」**というシステムの運用ルールを設定して、ハードウェア障害時のリスクを最小限に抑える「防波堤」としています。

2. システム構築・維持の複雑さ（属人化のリスク）

環境依存:
Pythonスクリプト、Google Cloud Platformの認証設定（JSONキー）、Macのフォルダ構造（/Users/xxxxxxm1/...）、LaunchAgentによるデーモン管理など、多くの依存関係の上に成り立っています。

トラブルシューティングの難易度:
もし「ボタンを押しても動かない」という事態になった場合、原因がGoogle APIの仕様変更なのか、ローカルのPython環境なのか、デーモンの停止なのかを切り分けるスキルが求められます。そんな理由もあって、ブログで中身を公開するとともに、AI(Gemeni/ChatGPTなど)の支援が受けやすいように考えています。

（２）自宅のどんな場所で使っているのか。

棚田システムは非常に柔軟で、M1Mac miniで十分だし、その外付けドライブであれば（というかM1Macが認識できるドライブであれば)どれでも選定できます。現状、下の図の赤丸T0T1T2に棚田システムを設定しています。調べてみて自分で驚いたのですが、外付けドライブを11個も使っていました。まだあと外してあるものも数個あります。別に壊れているわけではないのに。資源やお金を無駄にしてきたと思います。
世界全体が巨大なRAIDで動いているために、実際どれくらい冗長に重複所有になっているか。AI需要がそれを爆増させているわけなので、あとあと、とてつもない廃棄物が出る。バブルの崩壊が起きそうですね。。ああ怖い。有効活用のことを本気で考えるべき時がやってきそうな気がします。

棚段の基本構成は、作業段(T0)、保管段(T1)、長期保管段(T2)の３構成ですが、流出流入の関係を規定すれば、もっと増やすこともできますし、逆に、２構成にするのもいいと思います。実際、私は、高齢者ですので、これからは減らす方向でいきたいと思っています。

（３）実装

下記のトグルボックスにある青ボタンを押してtxtファイルをダウンロードして、AI(Gemini/ChatGPTなど)に理解させ、ご自身の環境に合わせた実装手順をお進みください。

実装手順

DAS棚田処理_メタデータ実データ更新アルゴリズム：

DAS棚田処理_メタデータDB仕様書：

DAS棚田管理_メタデータ処理py_shコード：
要約：Google Sheetsの「tanada」シートを設定CSV（tanada.csv）へ同期し、そのD列「転出パス」配下を全走査して世代SQLite（scan DB）を作成、さらにscan DB＋tanada.csvから全件の計画SQLite（plan DB）を1つ生成して「KEEP/MOVE/EXCLUDE」と新旧パス（abs_path/to_abs_path）を確定する一連のメタデータ用パイプライン。D列は1セル内の「,」や改行で複数パス指定可として分解し、重複は深いroot優先で排除。analyzeでは処理idごとに「転出パス1つ・転入パス1つ・除外パス複数可」を強制し、除外容量を差し引いた限度内でmtime降順に累積して新段位を決定、逆流（転出段≥転入段）はpipelineで拒否。最後にplan DBを集計し「どこ→どこへ/件数/容量」をMail.appで通知（print-only可）。das_runner.shがexport→pipeline→notifyをボタン1発で実行するランチャ。

DAS棚田管理_実データ更新処理コード：
要約：このシステムは、Google Sheetsをインターフェースとしたファイル管理の自動化パイプラインです。tanada_apply_button_daemon.pyは、Google Sheets上の手動ボタン（A10）によるAPPLY要求のみを監視し、深夜時間帯を除いてtanada_apply.pyを起動します。apply_runner.shは、SheetsのA8セルからファイル移動計画DBのパスを読み込み、それを固定名の適用DBにコピーし、tanada_apply.pyを実行するためのシェルスクリプトです。コアロジックを担うtanada_apply.pyは、適用DBに記録されたアクション（主にファイルの移動）をDRYRUNまたはAPPLYモードで実行します。このスクリプトは、「現段位がT0ではないファイルを新段位T0へ移動する」ポリシー違反を最優先でチェックし、違反があれば直ちに処理を停止する安全機構を備えています。処理結果はSheetsの指定セルにフィードバックされます。tanada_make_apply_plan_db.pyは、シミュレーション結果DBから、tanada_apply.pyが使用する固定名の適用計画DBを生成し、古いDBは世代管理してアーカイブします。com.xxxxxxxxm1.tanada_apply_button_daemon.plistは、デーモンをmacOSのLaunchAgentとして自動起動・常駐させ、必要な環境変数を設定します。このパイプラインは、手動トリガーと厳格な安全ポリシーにより、ファイル移動の誤操作を防ぎながらも自動化を実現しています。

DAS棚田管理_廃棄処理の規定：

コード(スクリプト)をもっと知りたい方はこちらへ↓

（４）まとめ