「ZimaOS Premium Snapshot Script」は、ファイルシステム／VMの意味でのZimaOSスナップショットではありません。Btrfsスナップショットやバックアップイメージを作成するものでもありません。これは、システムバージョン、リソース使用量、温度、ファイルシステム、RAIDの状態、SMARTヘルス、Dockerコンテナ、AppDataのサイズ、ネットワーク設定、上位プロセスなどの診断レポートを収集するコミュニティ製のBashスクリプトです。
そのため、サポートに役立つ可能性がある一方、生成されたテキストには、公開したくない環境の詳細が含まれることもあります。Zima-Giorgioはこのアイデアを評価し、改良版のレポートファイルを次の場所に保存することを提案しました。 /DATA その場所のほうがFilesからアクセスしやすいためです。このスレッドで、IceWhaleがそのスクリプトを組み込みの診断ツールとして採用または認定したわけではありません。
スクリプトは人が読みやすい1つのシステムレポートを作成します
ソーススクリプトは次の情報を収集します。
- ZimaOSのバージョン、バリアント、ビルド日、ホスト名、メーカー、モデル
- CPU負荷、メモリ、スワップ、温度
- ファイルシステムの使用状況とディスクレイアウト
- RAIDとBtrfsの状態
- ディスクのSMARTヘルス
- 実行中および終了済みのDockerコンテナ
- AppDataとMain-Storageのディレクトリサイズ
- IPv4インターフェース、ブリッジ、デフォルトルート
- CPUとメモリの使用率が高いプロセス。
診断レポートはバックアップでもファイルシステムスナップショットでもありません
「スナップショット」という言葉は誤解を招く可能性があります。このスクリプトはシステム情報をテキストファイルに書き込むだけで、復元用にアプリケーションのデータベース、ファイル、コンテナレイヤー、ある時点のストレージ状態を取得するものではありません。
復旧目的には、ZimaOS Backup、アプリケーション対応のエクスポート、RAID保護、または実際のファイルシステム／VMスナップショットツールを使用してください。
元のスクリプトはMain-Storageに書き込みました
V1スクリプトは次のものを作成しました。
/media/Main-Storage/Zima_snapshot/そして、そこに日付付きのテキストレポートを保存していました。このパスは、ユーザーのストレージ領域の実際の名前がMain-Storageであることを前提としています。
別のシステムでは、マウントポイントが利用できない場合、そのパスをハードコーディングすると失敗したり、意図しない場所に書き込まれたりする可能性があります。
Zima-Giorgioはアクセスしやすい場所として /DATA を提案
最終的なソースへの返信で、Zima-Giorgioは、プロジェクトが改良を続けるなら、出力ファイルを次の場所に保存することを提案しました。 /DATA そのディレクトリのほうがFilesアプリからアクセスしやすいためです。
これはコミュニティプロジェクトに対する公式のフィードバックであり、IceWhaleがそのスクリプトを統合したという発表ではありません。
SMART出力はデバイスごとに解釈する必要があります
このサンプルレポートには、温度、再割り当てセクタ、保留中のセクタ、CRCエラー、電源投入時間など、従来のHDDのSMARTフィールドが表示されていました。また、NVMeデバイスについては「SMART not available」と表示されていました。これは、スクリプトの単純な解析では、NVMeに相当する出力を生成できなかったためです。
このスクリプトで「利用不可」と表示されたことを、NVMeに健康状態のテレメトリがない証拠と解釈しないでください。
このスクリプトは作成者のRAID 5構成を前提に作成されています
サンプルでは、 md0 さらに「RAID5ステータス」セクションを出力します。別のZimaOS環境では、RAID 1、RAID 6、JBOD、ZFS、単一ディスク、または名前の異なるmdデバイスを使用している可能性があります。
スクリプトを再利用する前に、ハードコードされたデバイス、マウントパス、ファイルシステムに関する前提をすべて確認してください。
Dockerの出力からアプリケーションの一覧が露呈する可能性があります
レポートにはコンテナイメージ名とアプリケーション名が含まれます。これはサポート担当者には役立ちますが、公開ペーストでは、実行中のサービス、インストールされているバージョン、場合によっては古くなったアプリケーションまで明らかになる可能性があります。
信頼できるサポートチャネル以外にレポートを投稿する場合は、不要なサービス名を伏せてください。
ネットワーク出力から内部トポロジーが露呈する可能性があります
サンプルレポートには、インターフェース名、LAN IPアドレス、仮想ネットワーク、Dockerブリッジ、デフォルトルートが記載されています。投稿されたサンプルでは、作成者がIP情報の一部を手動でマスクしています。
レポートを一般公開する前に、次の点を確認してください。
- IPアドレスとサブネット。
- ホスト名。
- VPNまたはオーバーレイインターフェース名。
- マウント名と共有名。
- アプリケーション名またはコンテナ名。
- 個人を特定できる情報を含むパス。
読み取り専用の診断を優先する
この種のスクリプトの強みは、システム情報、ディスク使用量、SMARTクエリ、Dockerの一覧表示、プロセスの検査など、読み取り専用のコマンドで有用なトラブルシューティングデータの大部分を収集できることです。
診断スクリプトが、サービスを密かに再起動したり、Dockerを整理したり、RAIDメタデータを変更したり、ログを削除したりしてはいけません。証拠の収集と修復作業は分けてください。
現在のZimaOSは、ストレージとアプリに関するより多くの診断情報をすでに提供しています
現在の「設定」>「アプリ」では、アプリケーションごとのストレージ使用量とキャッシュの制御を確認できます。一方、「ストレージ」ではディスクの健全性とアレイ情報を確認できます。まずは組み込みの可視化機能を使い、サポートでより広範な1ファイルのシステムスナップショットが必要になった場合に、コミュニティレポートを追加してください。
現在のアプリストレージ可視化ツールを使えば、カスタムスクリプトなしで、容量に関する多くの疑問に答えられます。
診断スナップショットに関するよくある質問
このスクリプトは復元可能なシステムスナップショットを作成しますか？
いいえ。テキスト形式の診断レポートを作成します。
IceWhaleはこのスクリプトを正式に採用しましたか？
いいえ。Zima-Giorgioはこれを称賛し、レポートを次の場所に保存することを提案しました /DATAただし、コード自体はコミュニティによって作成されたものです。
レビューなしでレポートを一般公開すべきですか？
いいえ。IPアドレス、トポロジー、ストレージ名、アプリケーションの一覧、その他の環境情報が露出する可能性があります。
