バックアップを取ると便利だと示唆する情報源をいくつか見てきました/etc
。たとえば、「友人や家族のために Debian マシンをサポートする」というプレゼンテーションなどです。
本格的なバックアップには、明確に定義された復元プロセスも必要です (定期的にテストできます :-)。
これらのシステムファイルをどのように復元しますか?所有権情報を含むバックアップからtar
? 機能する復元プロセスの例を挙げてください。前提条件をすべて述べてください。バックアップ ツールは、または など、任意のものを想定できますetckeeper
。
特定の所有者を持つファイルの例:
$ ls -l|grep -v "root root"
total 2240
-rw-r-----. 1 root brlapi 33 Nov 15 21:32 brlapi.key
-rw-r-----. 1 root chrony 481 Nov 21 11:03 chrony.keys
drwxr-xr-x. 4 root lp 4096 Apr 18 10:58 cups
-rw-------. 1 tss tss 7046 Feb 5 2016 tcsd.conf
答え1
私がやっている方法はインストールすることです等キーパー。Debian および派生製品にうまく統合されています。Etckeeper は権限の記憶を処理します (ただし、SELinux ラベルは記憶しません)。バックアップは、バージョン管理リポジトリ (など)/etc
をバックアップするというよく知られた問題に簡略化されます。git pull
/etc
バックアップを復元するには:
- デフォルトのインストールを実行します (元のものと同じデフォルトのインストール)。
etckeeper
必要なバージョン管理システムをインストールします。/etc
(git clone
および同等のもの)のバックアップを復元しますgit checkout
。sourcejedi が指摘しているように、ユーザー ID またはグループ ID を動的に割り当てるパッケージをインストールする前に、これを実行する必要があります。- インストールされたパッケージのリストを復元し、インストールします。Etckeeperはそれを追跡しません。Debianおよび派生版では、 を使用して
apt-clone
ください。インストールされたパッケージの選択をある Debian システムから別の Debian システムに複製するにはどうすればよいですか? (Debian Wheezy))。 - リブート。
ハードウェアがまったく同じでない場合や、ファイルシステムが再フォーマットされている場合、動作しない可能性のあるものがいくつかあります。これは、バックアップを復元する場合によく発生します。復元をよりシームレスに動作させるには、構成内のどこにも一意のハードウェア識別子 (MAC アドレス、ディスクのシリアル番号など) やランダムな ID (ファイルシステムやパーティションの UUID ではなく、ファイルシステムのラベルを使用するなど) を使用しないようにします。
答え2
この回答は、他の場所で言及されていない、テストが必要ないくつかの問題のチェックリストです。これで、/etc の「バックアップ」に関する言及を無視できます。これには、復元方法も詳しく記載されていません。 このチェックリストが完全かどうかはテストしていません。
質問では特に言及されていないが、次の手順では、パッケージのアップグレード中に etckeeper で頻繁に発生するバージョン依存の変更やその他の変更も無視されます。少なくとも、OpenWrt を実行するルーターなど、それが問題にならないよりシンプルなシステムがあるはずです。
- 前提: このバックアップには具体的には が含まれます
/etc
。 - 前提: 異なる UUID で再作成された可能性のあるファイルシステムへの参照をどのように処理するかもわかっています
/etc/fstab
。 - 前提:対象システムには余分なバックアップと比較した場合、ユーザー数が大幅に減少します。たとえば、オペレーティング システムを新規インストールした場合、最初のユーザーは同じ名前 (および UID) で作成され、アップグレード中に OS に追加のサービスが追加されていません。これは、Debian の安定リリースでは当てはまる可能性がありますが、ローリング リリース ディストリビューションでは確実に当てはまりません。
- 前提: インストールプロセスは割り当てられたUID(パッケージのインストール順序)に関して完全に決定論的である。そしてこれはリポジトリ内の新しいアップデートの影響を受けません。通常のパッケージマネージャは決定論的であると私は信じています。繰り返しますが、Debian stableはおそらく信頼できますが、ローリングリリースは信頼できません。両者の間には不確実な領域があります。また、更新リポジトリにアクセスせずに、インストーラのまったく同じバージョンを実行するように設定することもできます(復元中は両方とも)。そして(元のシステムをインストールしたとき)
- バックアップ用の復元ツールはすでにインストールされているはずです :)。
- 以下の手順では、Linuxの従来のシャドウパスワードファイルも想定しています。BSDシステムでは異なるファイル名を使用します。一部の特殊用途のLinuxシステムでは、大幅に異なるスタイル。
- で定義されたパスワードを使用せずに「レスキューモード」で起動できること
/etc
、およびバックアップにアクセスするために複雑なものを必要としないことを確認してください。これは危険な行為です。ディスク暗号化がこれをどのように処理するかはわかりませんが、バックアップと同じパスワードを使用すると役立つ可能性があります。以下の手順は、別の「レスキュー」から実行した場合は機能しないことに注意してください。システム「」。 mv /etc/ /etc.installer # can be removed later
mkdir /etc && chmod 755 /etc
ID_FILES=passwd group shadow
for i in $ID_FILES; do cp /etc.installer/${i} /etc; done
i
これで、内の各ファイルについて、バックアップからターゲット システムに$ID_FILES
復元できるようになります。/etc/${i}
- 今なら復元できます全てファイルの所有権情報も含みます。
- 今ならできるSELinuxラベルを再適用するまたは必要に応じて同等のもの。
バックアップが etckeeper リポジトリ (および追加ファイルなし) である場合、手順 12 では、それを にコピー/クローンして/etc
から を実行しますetckeeper init
。手順 10 ~ 12 はスキップできます。
オープンWrt
システム設定のバックアップ/復元は、Web インターフェイスの特定の機能を使用して、OpenWrt ルーターでサポートされています。
/etc
私の OpenWrt 15.05.1 システムでは、 (または他の場所)のファイルを所有しているユーザーは と のみですroot
。OpenWrtnobody
の新規インストールにはこれらのユーザーがすでに含まれていると想定しても問題ありません。
追加のユーザーを追加した OpenWrt セットアップがこのツールによって正しく処理されるかどうかはわかりません。