Ubuntu 26.04 講座 / Ubuntu 設定・パッケージ一覧・ユーザーデータバックアップ

Ubuntuのバックアップは、復元する設定・ユーザーデータ・アプリデータを決め、オリジナルの障害と分離された場所に保管した後、実際に復元できるか確認する必要があります。パッケージリストやVMスナップショットだけではデータの復元は完結しません。この記事では、バックアップの範囲を整理し、オリジナルを上書きしない小さな復元実習を提供します。

何を復元するかまず決める

稼働中のデータベースのファイルを単純にtarでコピーすると、異なる時点の内容が混ざる可能性があります。アプリがサポートするダンプや停止・フリーズ手順を使用し、複数のストレージを一緒に復元する必要があるか確認します。ACL・拡張属性が必要な資料については、選択したツールがこれを保持して復元できるかを別途試験します。

パッケージと設定場所を記録する

次のコマンドは一般ユーザーのホーム以下に新しい一覧フォルダを作成し、パッケージをインストールまたは削除しません。一覧にはユーザー名・リポジトリアドレスなど運用情報が含まれる可能性があるためアクセスを制限します。この一覧自体には設定ファイルやユーザーファイルの内容は含まれません。

(
set -eu
umask 077
inventory_dir=$(mktemp -d "$HOME/ubuntu-inventory.XXXXXX")
apt-mark showmanual > "$inventory_dir/apt-manual.txt"
dpkg-query -W -f='${binary:Package}\t${Version}\n' > "$inventory_dir/dpkg-versions.tsv"
if command -v snap >/dev/null 2>&1; then
    snap list > "$inventory_dir/snap-list.txt"
fi
cat /etc/os-release > "$inventory_dir/os-release.txt"
printf "%s\n" "$inventory_dir"
)

復元時に一覧全体を無条件で再インストールせず、現在のリリースで必要なパッケージとリポジトリがサポートされているかを確認します。サーバーを新規に作成する場合、machine-id・SSHホストキー・固定IPのように機器ごとに異なる値は設定バックアップと区別します。同一サーバーの復旧と別サーバーの複製は別作業です。

小さなデータでバックアップ・復元ラウンドトリップを試す

以下の全コードを ~/backup-roundtrip-lab.sh に保存し、bash ~/backup-roundtrip-lab.sh で実行します。tar・sha256sum・cmp が必要で、sudo は使いません。新しい一時フォルダのサンプルファイルのみを扱います。同じディスクでの演習のため、独立したバックアップ保管の代わりにはなりません。

set -eu
umask 077
lab_dir=$(mktemp -d)
mkdir "$lab_dir/source" "$lab_dir/restored"
printf "original data\n" > "$lab_dir/source/note with spaces.txt"
tar -C "$lab_dir/source" -cpf "$lab_dir/data.tar" .
(
    cd "$lab_dir"
    sha256sum data.tar > data.tar.sha256
    sha256sum -c data.tar.sha256
)
tar -tf "$lab_dir/data.tar"
tar -C "$lab_dir/restored" -xpf "$lab_dir/data.tar"
cmp "$lab_dir/source/note with spaces.txt" "$lab_dir/restored/note with spaces.txt"
printf "Round trip passed: %s\n" "$lab_dir"

チェックサムでアーカイブが作成時と同じか確認し、tar のリストで含まれる名前を確認します。最後の cmp が成功し、Round trip passed が表示されていれば、サンプルファイルの内容が復元されたと判断できます。暗号化・アクセス権・アプリ実行まで検証したわけではありません。不明なアーカイブを管理者権限で解凍せず、実際の復元も隔離された空のディレクトリで開始します。

実際の Nginx 設定とユーザーフォルダをバックアップする

Nginx 演習を終えたサーバーの /etc/nginx とホーム内の一般的なドキュメントフォルダひとつを対象とします。実際のフォルダを決め、編集・同期・アプリ書き込みを止めた一貫した状態を準備します。稼働中の DB や Docker ボリュームをこのファイルバックアップで代替しません。自動マウント講座の別バックアップディスクのマウントポイント・UUID を記録し、元のものと異なる装置か確認します。

次の全てを ~/backup-course-data.sh に保存します。Bash・GNU tar・util-linux の findmnt・coreutils の realpath/sha256sum が必要です。最初の引数はユーザー資料フォルダー、二番目はディスク自体のマウントポイント、三番目は UUID です。bash ~/backup-course-data.sh "$HOME/Documents/course-data" /srv/backup 実際のUUID を例にしますが、すべて実際の値に置き換えます。

set -eu
umask 077
if [ "$#" -ne 3 ]; then
    printf 'Usage: bash backup-course-data.sh SOURCE_DIR BACKUP_MOUNT EXPECTED_UUID\n' >&2; exit 2
fi
source_dir=$(realpath -- "$1")
backup_mount=$(realpath -- "$2")
expected_uuid=$3
case "$source_dir" in
    "$HOME"/*) ;;
    *) printf 'Choose a specific ordinary-data folder inside your home.\n' >&2; exit 1 ;;
esac
test -d "$source_dir"
if [ -z "$expected_uuid" ] || [ "$expected_uuid" = REPLACE_WITH_VERIFIED_UUID ]; then
    printf 'Record the actual backup filesystem UUID first.\n' >&2; exit 1
fi
actual_uuid=$(findmnt -rn --mountpoint "$backup_mount" -o UUID || true)
if [ "$actual_uuid" != "$expected_uuid" ]; then
    printf 'Expected backup filesystem is not mounted; stop.\n' >&2; exit 1
fi
for original in "$source_dir" /etc/nginx; do
    original_uuid=$(findmnt -rn --target "$original" -o UUID)
    if [ -z "$original_uuid" ] || [ "$original_uuid" = "$actual_uuid" ]; then
        printf 'Use a separate verified backup filesystem.\n' >&2; exit 1
    fi
done
case "$backup_mount/" in
    "$source_dir/"*) printf 'Backup must be outside the source tree.\n' >&2; exit 1 ;;
esac
sudo test -d /etc/nginx
df -h "$source_dir" "$backup_mount"
set_dir=$(sudo mktemp -d "$backup_mount/ubuntu-course-backup.XXXXXX")
sudo chmod 0700 "$set_dir"
sudo tar --acls --xattrs --numeric-owner -C / -cpf "$set_dir/nginx.tar" etc/nginx
sudo tar --acls --xattrs --numeric-owner -C "$source_dir" -cpf "$set_dir/user-data.tar" .
sudo sh -c 'cd "$1" && sha256sum nginx.tar user-data.tar > SHA256SUMS && sha256sum -c SHA256SUMS' sh "$set_dir"
printf 'Backup set: %s\n' "$set_dir"

マウントがない場合や UUID が異なる場合は、アーカイブ作成前に中断します。成功すると新しいセットのパスと二つのチェックサムの OK が表示されます。設定に秘密情報が含まれる可能性があるため、セットは root 専用の 0700 に制限しますが、これは紛失に備えた暗号化ではありません。バックアップの保存・暗号化方針も定め、ACL・拡張属性の保持は実際のファイルシステムで復元して確認します。

空の別の場所に復元して元と比較する

自身が作成した信頼できるセットのみ使用します。次を ~/restore-course-data.sh に保存し、bash ~/restore-course-data.sh バックアップセットのパス で実行します。新しい /var/tmp ディレクトリにのみ展開し、運用の /etc/nginx やユーザーの元のファイルを上書きしません。十分な空き容量と UID・GID の対応を事前に確認します。

set -eu
if [ "$#" -ne 1 ]; then
    printf 'Usage: bash restore-course-data.sh BACKUP_SET_DIRECTORY\n' >&2; exit 2
fi
set_dir=$(realpath -- "$1")
sudo test -f "$set_dir/SHA256SUMS"
sudo sh -c 'cd "$1" && sha256sum -c SHA256SUMS' sh "$set_dir"
restore_dir=$(sudo mktemp -d /var/tmp/ubuntu-course-restore.XXXXXX)
sudo chmod 0700 "$restore_dir"
sudo mkdir "$restore_dir/config" "$restore_dir/data"
sudo tar --acls --xattrs --same-owner -C "$restore_dir/config" -xpf "$set_dir/nginx.tar"
sudo tar --acls --xattrs --same-owner -C "$restore_dir/data" -xpf "$set_dir/user-data.tar"
sudo ls -ldn "$restore_dir/config/etc/nginx" "$restore_dir/data"
printf 'Isolated restore: %s\n' "$restore_dir"

出力された実際の復元パスを次の変数に入れ、バックアップ後に変更していないオリジナルと比較します。diffが無出力で終了コード0は同じ内容、1は差異を意味します。オリジナルをバックアップ後に修正していた場合、差異があるからといってバックアップが破損しているとは断定しません。その他のエラーは権限・ファイルの存在から確認します。

restore_dir=/var/tmp/REPLACE_WITH_PRINTED_RESTORE_DIRECTORY
source_dir="$HOME/Documents/course-data"
sudo diff --no-dereference -r /etc/nginx "$restore_dir/config/etc/nginx"
sudo diff --no-dereference -r "$source_dir" "$restore_dir/data"

重要なファイルの内容と ls -ln の数字による所有者・モード、必要であれば getfacl/getfattr の ACL・拡張属性を比較します。ツールがない場合は acl・attr パッケージを準備します。ファイルの抽出だけでサービス復元が完了したとみなさず、実際の障害復旧は別のサーバで設定確認・アプリ機能テストまで経て適用します。今回の比較フォルダはパス・内容を確認した後、自分が作成したものだけ整理します。

独立した保存場所と障害検知の準備

外付けディスクや別ホストを使用する場合、保存ディレクトリがあるという理由だけで接続されたと判断しません。findmnt の対象マウント SOURCE・UUID の記録値と比較し、異なる場合は書き込みを中止します。マウントされていない空のフォルダに書き込むとシステムディスクを消費する可能性があります。保存容量・復号可能かどうか・他の場所やオフラインのバックアップ世代も復旧目的に合わせて設計します。

Ubuntuのシェルスクリプトによるバックアップガイドには、tarや別のディレクトリに復元する例があります。

自動化は手動復元に成功した後に行います。終了コード・最後の成功時刻・保管世代・ディスク容量不足を記録し、失敗通知が届くかをテストします。ハッシュを書き込み可能な同じ場所に置くだけでは改ざんを防げないため、必要に応じて独立した検証記録や変更不能な保管も検討します。

資料とサービスの動作で復旧完了を判断する

復元先でファイル数・重要ファイルの内容・所有者・権限を確認し、アプリの読み書きやユーザーのログインをテストします。DNS・証明書・共有・バックアップ再開も対象に応じて確認します。復旧時間と失われた変更範囲を記録し、許容時間・損失範囲を超える場合は周期や手順を改善します。必要な資料を確保する前に障害元のディスクを初期化しません。