Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

2.3. 自動回復機能を使用したバックアップの復元

必要なデータが削除または破損するシステムイベントが発生した後でも、バックアップを復元できます。自動リカバリーを使用してバックアップを復元するには、次の手順を実行します。自動リカバリーは最新のバックアップを選択して復元します。これまでに自動リカバリーを使用して復元されたバックアップは、PATH/restored ディレクトリーに移動されます。

前提条件

  • MicroShift を停止している。

手順

  1. 次のコマンドを実行して、バックアップディレクトリーから最新のバックアップを復元します。 

    $ sudo microshift restore --auto-recovery <path_of_directory>
    1
    1
    <path_of_directory> を、バックアップを保存するディレクトリーのパスに置き換えます。たとえば、/var/lib/microshift-auto-recovery です。
    注記
    • --auto-recovery オプションは、後で調査できるように MicroShift データを /var/lib/microshift-auto-recovery/failed/ にコピーし、最新のバックアップを選択して復元します。
    • --dont-save-failed オプションは、失敗した MicroShift データのバックアップを無効にします。

    出力例

    ??? I1104 09:19:28.617225    8950 state.go:80] "Read state from the disk" state={"LastBackup":"20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"}
??? I1104 09:19:28.617323    8950 storage.go:78] "Auto-recovery backup storage read and parsed" dirs=["20241022101255_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","20241022101520_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1","restored"] backups=[{"CreationTime":"2024-10-22T10:12:55Z","Version":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"},{"CreationTime":"2024-10-22T10:15:20Z","Version":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"},{"CreationTime":"2024-10-22T10:15:28Z","Version":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"},{"CreationTime":"2024-11-04T09:18:52Z","Version":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"}]
??? I1104 09:19:28.617350    8950 storage.go:40] "Filtered list of backups - removed previously restored backup" removed="20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0" newList=[{"CreationTime":"2024-10-22T10:12:55Z","Version":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"},{"CreationTime":"2024-10-22T10:15:20Z","Version":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"},{"CreationTime":"2024-11-04T09:18:52Z","Version":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"}]
??? I1104 09:19:28.633237    8950 system.go:58] "OSTree deployments" deployments=[{"id":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1","booted":true,"staged":false,"pinned":false},{"id":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","booted":false,"staged":false,"pinned":false}]
??? I1104 09:19:28.633258    8950 storage.go:49] "Filtered list of backups by version" version="default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1" newList=[{"CreationTime":"2024-11-04T09:18:52Z","Version":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"}]
??? I1104 09:19:28.633268    8950 restore.go:170] "Potential backups" bz=[{"CreationTime":"2024-11-04T09:18:52Z","Version":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"}]
??? I1104 09:19:28.633277    8950 restore.go:173] "Candidate backup for restore" b={"CreationTime":"2024-11-04T09:18:52Z","Version":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"}
??? I1104 09:19:28.634007    8950 disk_space.go:33] Calculated size of "/var/lib/microshift-auto-recovery/20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1": 261M - increasing by 10% for safety: 287M
??? I1104 09:19:28.634096    8950 disk_space.go:44] Calculated available disk space for "/var/lib": 1658M
??? I1104 09:19:28.634507    8950 disk_space.go:33] Calculated size of "/var/lib/microshift": 261M - increasing by 10% for safety: 287M
??? I1104 09:19:28.634522    8950 disk_space.go:44] Calculated available disk space for "/var/lib/microshift-auto-recovery": 1658M
??? I1104 09:19:28.649719    8950 system.go:58] "OSTree deployments" deployments=[{"id":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1","booted":true,"staged":false,"pinned":false},{"id":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","booted":false,"staged":false,"pinned":false}]
??? I1104 09:19:28.653880    8950 atomic_dir_copy.go:66] "Made an intermediate copy" cmd="/bin/cp --verbose --recursive --preserve --reflink=auto /var/lib/microshift /var/lib/microshift-auto-recovery/failed/20241104091928_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1.tmp.22742"
??? I1104 09:19:28.657362    8950 atomic_dir_copy.go:66] "Made an intermediate copy" cmd="/bin/cp --verbose --recursive --preserve --reflink=auto /var/lib/microshift-auto-recovery/20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1 /var/lib/microshift.tmp.482"
??? I1104 09:19:28.657385    8950 state.go:40] "Saving intermediate state" state="{\"LastBackup\":\"20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1\"}" path="/var/lib/microshift-auto-recovery/state.json.tmp.41544"
??? I1104 09:19:28.662438    8950 atomic_dir_copy.go:115] "Renamed to final destination" src="/var/lib/microshift.tmp.482" dest="/var/lib/microshift"
??? I1104 09:19:28.662451    8950 state.go:46] "Moving state file to final path" intermediatePath="/var/lib/microshift-auto-recovery/state.json.tmp.41544" finalPath="/var/lib/microshift-auto-recovery/state.json"
??? I1104 09:19:28.662521    8950 atomic_dir_copy.go:115] "Renamed to final destination" src="/var/lib/microshift-auto-recovery/failed/20241104091928_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1.tmp.22742" dest="/var/lib/microshift-auto-recovery/failed/20241104091928_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"
??? I1104 09:19:28.662969    8950 atomic_dir_copy.go:115] "Renamed to final destination" src="/var/lib/microshift-auto-recovery/20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0" dest="/var/lib/microshift-auto-recovery/restored/20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"
??? I1104 09:19:28.662983    8950 restore.go:141] "Auto-recovery restore completed".

    重要
    • restore コマンドは復元後に MicroShift を再起動しません。このコマンドを実行した時点で、MicroShift サービスはすでに障害で停止しているか、ユーザーによって停止されています。
    • MicroShift は、どのファイルシステムのディスク領域も監視しません。自動化によって古いバックアップの削除が処理されるようにする必要があります。たとえば、このプロセスを auto-recovery サービスに追加したり、定期的に実行する別のサービスを追加したりできます。

  2. 次のコマンドを実行して MicroShift を再起動します。 

    $ sudo systemctl restart microshift

検証

  • 次のコマンドを実行して、MicroShift が正常に開始されたことを確認します。 

    $ oc get pods -A

    出力例

    NAMESPACE                   NAME                                                     READY   STATUS   RESTARTS  AGE
default                     i-06166fbb376f14a8bus-west-2computeinternal-debug-qtwcr  1/1     Running  0		    46m
kube-system                 csi-snapshot-controller-5c6586d546-lprv4                 1/1     Running  0		    51m
openshift-dns               dns-default-45jl7                                        2/2     Running  0		    50m
openshift-dns               node-resolver-7wmzf                                      1/1     Running  0		    51m
openshift-ingress           router-default-78b86fbf9d-qvj9s                          1/1     Running  0		    51m
openshift-ovn-kubernetes    ovnkube-master-5rfhh                                     4/4     Running  0		    51m
openshift-ovn-kubernetes    ovnkube-node-gcnt6                                       1/1     Running  0		    51m
openshift-service-ca        service-ca-bf5b7c9f8-pn6rk                               1/1     Running  0		    51m
openshift-storage           topolvm-controller-549f7fbdd5-7vrmv                      5/5     Running  0		    51m
openshift-storage           topolvm-node-rht2m                                       3/3     Running  0		    50m

    注記

    この出力例は、基本的な MicroShift を示しています。オプションの RPM をインストールしている場合は、それらのサービスを実行している Pod のステータスも出力に表示されるはずです。

2.3.1. RPM システムでの自動リカバリーの使用
リンクのコピー

MicroShift が failed 状態になると、systemd サービスは microshift-auto-recovery.service ユニットを開始します。このユニットは auto-recovery の復元プロセスを実行します。

ユースケースとして、systemd サービスを使用する RPM システムの自動リカバリープロセスを自動化する次の例を考えてみましょう。

手順

  1. 次のコマンドを実行して、microshift のディレクトリーを作成します。 

    $ sudo mkdir -p /usr/lib/systemd/system/microshift.service.d

  2. microshift.service が失敗したときに systemd に microshift-auto-recovery.service を実行するように指示するには、次のコマンドを実行して 10-auto-recovery.conf ファイルを作成します。 

    $ sudo tee /usr/lib/systemd/system/microshift.service.d/10-auto-recovery.conf > /dev/null <<'EOF'
[Unit]
OnFailure=microshift-auto-recovery.service
StartLimitIntervalSec=25s
    1 
    
EOF
    1
    低速なシステムの場合は、StartLimitInterval 値をデフォルトの 10s からより大きな値に増やします。値が低すぎると、systemd が microshift systemd サービスを失敗としてマークしなくなり、OnFailure= サービスがトリガーされなくなります。

  3. 次のコマンドを実行して、microshift-auto-recovery.service ファイルを作成します。 

    $ sudo tee /usr/lib/systemd/system/microshift-auto-recovery.service > /dev/null <<'EOF'
[Unit]
Description=MicroShift auto-recovery

[Service]
Type=oneshot
ExecStart=/usr/bin/microshift-auto-recovery

[Install]
WantedBy=multi-user.target
EOF

  4. 次のコマンドを実行して、microshift-auto-recovery スクリプトを作成します。 

    $ sudo tee /usr/bin/microshift-auto-recovery > /dev/null <<'EOF'
#!/usr/bin/env bash
set -xeuo pipefail

# If greenboot uses a non-default file for clearing boot_counter, use boot_success instead.
if grep -q  "/boot/grubenv" /usr/libexec/greenboot/greenboot-grub2-set-success; then
    if grub2-editenv - list | grep -q ^boot_success=0; then
        echo "Greenboot didn't decide the system is healthy after staging new deployment."
        echo "Quitting to not interfere with the process"
        exit 0
    fi
else
    if grub2-editenv - list | grep -q ^boot_counter=; then
        echo "Greenboot didn't decide the system is healthy after staging a new deployment."
        echo "Quitting to not interfere with the process"
        exit 0
    fi
fi

/usr/bin/microshift restore --auto-recovery /var/lib/microshift-auto-recovery
/usr/bin/systemctl reset-failed microshift
/usr/bin/systemctl start microshift

echo "DONE"
EOF

  5. 次のコマンドを実行してスクリプトを実行可能にします。 

    $ sudo chmod +x /usr/bin/microshift-auto-recovery

  6. 次のコマンドを実行してシステム設定を再ロードします。 

    $ sudo systemctl daemon-reload

2.3.2. RHEL for Edge での自動リカバリーの使用
リンクのコピー

ユースケースとして、ブループリントファイルで systemd を使用する Red Hat Enterprise Linux for Edge (RHEL for Edge) システムの auto-recovery プロセスを自動化する次の例を検討してください。

重要

systemd を使用する RHEL for Edge システムの auto-recovery プロセス全体をブループリントファイルに含める必要があります。

前提条件

  • Podman がインストールされている。
  • コマンドラインの composer-cli ツールがインストールされている。

手順

  1. オプション: composer-cli は /etc ディレクトリーにのみファイルを作成できるため、ブループリントが含まれる RPM にファイルをパッケージ化します。

  2. ブループリントファイルを作成するには、次の例を使用します。 

    [[customizations.directories]]
path = "/etc/systemd/system/microshift.service.d"

[[customizations.directories]]
path = "/etc/bin"

[[customizations.files]]
path = "/etc/systemd/system/microshift.service.d/10-auto-recovery.conf"
data = """
[Unit]
OnFailure=microshift-auto-recovery.service
"""

[[customizations.files]]
path = "/etc/systemd/system/microshift-auto-recovery.service"
data = """
[Unit]
Description=MicroShift auto-recovery
[Service]
Type=oneshot
ExecStart=/etc/bin/microshift-auto-recovery
[Install]
WantedBy=multi-user.target
"""

[[customizations.files]]
path = "/etc/bin/microshift-auto-recovery"
mode = "0755"
data = """
#!/usr/bin/env bash
set -xeuo pipefail
# If greenboot uses a non-default file for clearing boot_counter, use boot_success instead.
if grep -q  "/boot/grubenv" /usr/libexec/greenboot/greenboot-grub2-set-success; then
    if grub2-editenv - list | grep -q ^boot_success=0; then
        echo "Greenboot didn't decide the system is healthy after staging a new deployment."
        echo "Quitting to not interfere with the process"
        exit 0
    fi
else
    if grub2-editenv - list | grep -q ^boot_counter=; then
        echo "Greenboot didn't decide the system is healthy after staging a new deployment."
        echo "Quitting to not interfere with the process"
        exit 0
    fi
fi
/usr/bin/microshift restore --auto-recovery /var/lib/microshift-auto-recovery
/usr/bin/systemctl reset-failed microshift
/usr/bin/systemctl start microshift
echo "DONE"
"""
  3. 次の手順は、イメージのビルドの準備 を参照してください。

2.3.3. Image Mode for RHEL での自動リカバリーの使用
リンクのコピー

重要

Image Mode for RHEL はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

ユースケースとして、systemd サービスを使用する Image Mode for Red Hat Enterprise Linux (RHEL) システムの auto-recovery プロセスを自動化する次の例を検討してください。

重要

コンテナーファイルで systemd を使用する image mode for RHEL の auto-recovery プロセス全体を含める必要があります。

前提条件

  • bootc イメージの構築 の手順に従って、Containerfile を作成している。

  • 「RPM システムでの auto-recovery の使用」セクションで説明されているように 10-auto-recovery.conf ファイルと microshift-auto-recovery.service ファイルを作成した。

    重要

    10-auto-recovery.conf および microshift-auto-recovery.service の場所は、Containerfile を起点にする必要があります。

    たとえば、Containerfile へのパスが /home/microshift/my-build/Containerfile の場合、適切に埋め込むには systemd ファイルが隣接している必要があります。この例では、正しいパスは以下のとおりです。

    • /home/microshift/my-build/auto-rec/10-auto-recovery.conf
    • /home/microshift/my-build/auto-rec/microshift-auto-recovery.service
    • /home/microshift/my-build/auto-rec/microshift-auto-recovery
  • 「RPM システムでの auto-recovery の使用」セクションで説明されているように microshift-auto-recovery スクリプトを作成した。

手順

  1. 以下のスニペット例を使用して、image mode for RHEL イメージを準備するために使用するコンテナーファイルを更新します。 

    RUN mkdir -p /usr/lib/systemd/system/microshift.service.d
COPY ./auto-rec/10-auto-recovery.conf /usr/lib/systemd/system/microshift.service.d/10-auto-recovery.conf
COPY ./auto-rec/microshift-auto-recovery.service /usr/lib/systemd/system/
COPY ./auto-rec/microshift-auto-recovery /usr/bin/
RUN chmod +x /usr/bin/microshift-auto-recovery
    重要

    Podman は、コンテナーイメージをビルドするときに、コンテナー内のホストのサブスクリプション情報とリポジトリーを使用します。rhocp および fast-datapath リポジトリーがホスト上で利用できないと、ビルドは失敗します。

  2. 次のイメージビルドコマンドを実行して、ローカル bootc イメージを再構築します。 

    PULL_SECRET=~/.pull-secret.json
USER_PASSWD=<your_redhat_user_password>
IMAGE_NAME=microshift-4.18-bootc

sudo podman build --authfile "${PULL_SECRET}" -t "${IMAGE_NAME}" \
    --build-arg USER_PASSWD="${USER_PASSWD}" \
    -f Containerfile
    注記

    シークレットは、イメージのビルド中に次のように使用されます。

    • registry.redhat.io レジストリーからベース rhel-bootc:9.4 イメージをプルするには、podman --authfile 引数が必要です。
    • ビルド USER_PASSWD 引数は、redhat ユーザーのパスワードを設定するために使用されます。

検証

  • 次のコマンドを実行して、ローカル bootc イメージが作成されたことを確認します。 

    $ sudo podman images "${IMAGE_NAME}"

    出力例

    REPOSITORY                       TAG         IMAGE ID      CREATED        SIZE
localhost/microshift-4.18-bootc  latest      193425283c00  2 minutes ago  2.31 GB

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る