データバックアップ

← ShimoDocs Suite デプロイメント文書

この文書は、データバックアップの範囲、復旧要件、実行方法、および復旧後の検証項目について説明します ShimoDocs 民営化された環境。

この文書は以下の内容を含みます:

バックアップの範囲と責任の境界
データベースのバックアップとリカバリ要件
オブジェクトストレージのバックアップとリカバリ要件
リカバリ前の確認項目
リカバリ後の確認項目

このドキュメントには以下の内容は含まれていません：

初回インストールおよび展開手順
アップグレードおよび移行計画
サードパーティミドルウェアベンダー固有のリカバリツールの手順
本番インシデント対応プロセス

2. バックアップの範囲と責任の境界

2.1 バックアップの範囲

バックアップの範囲に含める必要があるデータは ShimoDocs 民間化された環境には以下が含まれます:

MySQL データ
MongoDB データ
Redis データ
オブジェクトストレージデータ
インストール構成および環境パラメータファイル

データディレクトリ、バックアップディレクトリ、およびバックアップ保持期間はクライアント側で統一的に管理されます。

2.2 責任範囲

バックアップおよびリカバリの責任の範囲は以下の通りです:

クライアント側は正式なバックアップポリシーの策定および実行を担当します。
クライアント側はバックアップファイルの保管、メディアのセキュリティ、および保持期間管理を担当します。
クライアント側はリカバリ演習、リカバリ承認、およびリカバリ結果の受け入れを担当します。
ShimoDocs 技術サポートおよびリカバリ操作の指導を提供できます。

外部ミドルウェア、自社構築オブジェクトストレージ、またはクライアント管理インフラが関与する場合、バックアップおよびリカバリ戦略は完全にクライアント側で実施されます。

3. リカバリ実行前の確認

データリカバリは高リスクの操作です。実行前に以下の確認を完了する必要があります。

3.1 対象の確認

リカバリ前に、以下の情報を明確にしてください：

対象環境
対象クラスター、ノード NAMESPACE
リカバリ対象データの範囲
リカバリポイントの時点
実行ウィンドウ

3.2 リスク確認

リカバリ前に以下の項目を確認してください：

このリカバリが現在のオンラインデータを上書きするかどうか
このリカバリにダウンタイムが必要かどうか
最新のバックアップが現在のオンラインデータに追加されているかどうか
リカバリ失敗後のロールバックポイントが明確になっているかどうか

3.3 バックアップ有効性確認

リカバリ前に以下を確認してください:

バックアップファイルが完全で読み取り可能であること
バックアップの時点がリカバリ目標を満たしていること
バックアップディレクトリが正しくマウントされていること
リカバリに必要なすべての設定ファイルが揃っていること
バックアップファイルがリカバリ可能性の確認を通過していること

4. バックアップ戦略

4.1 データベースバックアップ

データベースバックアップの基準は以下の通りです:

シナリオ	実行方法	頻度	保存期間	説明
使用 ShimoDocs 組み込みミドルウェア	システムスケジュールバックアップ	1日1回	7日間	クラスタ内のスケジュールタスクによって実行される
顧客自己管理のミドルウェアを使用	顧客側バックアップ	1日1回以上	7日以上	顧客側ポリシーに従って実行

データベースバックアップは少なくとも以下をカバーする必要があります:

MySQL
MongoDB
Redis

4.2 オブジェクトストレージバックアップ

オブジェクトストレージバックアップの基準は次の通りです:

データタイプ	実行方法	頻度	保存期間	説明
オブジェクトストレージの業務データ	コールドバックアップまたはディザスタリカバリ複製	業務レベルに従って実行	顧客ポリシーに従って実行	文書添付ファイルおよびファイルオブジェクトをカバー
オブジェクトストレージ構成データ	構成バックアップ	変更後の同期バックアップ	顧客ポリシーに従って実行	アクセスパラメータおよびマウント情報をカバー

オブジェクトストレージの複数コピーはクラスタの冗長性メカニズムの一部であり、データバックアップと同等ではありません。

4.3 構成ファイルのバックアップ

バックアップ範囲に含まれる構成は以下の通りです:

インストールパラメータ
ドメインおよびプロトコルの構成
外部依存アドレスおよびポート情報
オブジェクトストレージアクセス情報
業務関連の構成ファイル

5. データベースの復旧

このセクションはすべてのデータ復旧に適用されます MySQL, MongoDB、および Redis.

5.1 復旧前の準備

データベースのリカバリを実行する前に、次の準備を完了してください：

ターゲットノードにリカバリディレクトリを準備します。例えば、 /data/restore
回復するデータをリカバリディレクトリに配置します
ミドルウェアの設定がファイル内で現在の環境と一致していることを確認する global_config.json
リカバリノード、リカバリポイント、実行ウィンドウ、および承認情報を確認してください

5.2 バックアップタスクの確認

スケジュールされたデータベースのバックアップタスクを確認してください：

kubectl get cronjob

次の情報も記録してください：

CronJob 名
最終実行時間
直近の実行結果
バックアップファイルの保存ディレクトリ

5.3 実行の再開

データベースの復旧は一度限りのジョブで実行され、復旧スクリプトはバックアップイメージ内にあります。

実行手順は次の通りです:

リストアタスク一覧を準備する db-restore.yaml
に修正する spec.template.spec.nodeName 復旧ディレクトリがあるノードに
に修正する hostPath.path データを復元するディレクトリに
を実行する kubectl apply -f db-restore.yaml データ復元を行うためのコマンド

タスクリストのサンプルは次のとおりです:

apiVersion: batch/v1
kind: Job
metadata:
  labels:
    job-name: db-restore
  name: db-restore
spec:
  template:
    metadata:
      labels:
        job-name: db-restore
      name: db-restore
    spec:
      containers:
      - command:
        - /bin/sh
        - -c
        - cd /data/pri-init/scripts/backup && sh restore_all.sh
        image: registryo.shimo.im/smbase/backup:co
        imagePullPolicy: Always
        name: db-restore
        volumeMounts:
        - name: db-config
          mountPath: /data/pri-init/scripts/global_config.json
          subPath: global_config.json
        - name: data
          mountPath: /backup
      dnsPolicy: ClusterFirst
      nodeName: master-1
      volumes:
      - name: db-config
        configMap:
          name: init-invoker
          items:
          - key: global_config.json
            path: global_config.json
      - name: data
        hostPath:
          path: /data/restore
      imagePullSecrets:
      - name: ee
      restartPolicy: Never
      schedulerName: default-scheduler

5.4 実行手順

データベース復旧タスクを実行した後、次のデータがロールバックされます:

MySQL
MongoDB
Redis

復旧期間中、業務データが上書きされる可能性があります。実行前に完全なシャットダウンの手配とデータ確認を行ってください。

6. オブジェクトストレージの復旧

このセクションは次に適用されます MinIO および S3-互換オブジェクトストレージのリカバリ。

6.1 バックアップ方法

オブジェクトストレージの一般的なバックアップ方法は以下の通りです:

方法	適用シナリオ	説明
Rsync同期コピー	スタンドアロン環境	ディレクトリレベルのコールドバックアップに適しています
ディスクスナップショット	スタンドアロン環境	同じストレージプラットフォームでの高速復旧に適しています
`mc mirror`	スタンドアロンまたはクラスタ環境	オブジェクトデータのコールドバックアップおよびリカバリに適しています
サイトレプリケーション / バケットレプリケーション	クラスタ環境	ディザスタリカバリレプリケーションに適しています

6.2 実行再開

スタンドアロン環境で一般的に使用されるリカバリ方法は以下の通りです:

バックアップにRsyncを使用する場合、データディレクトリを復元するために逆同期を実行します

rsync -av backup:/data/minio/ /data/minio/

バックアップに使用する場合 mc mirror 逆ミラーレストアを実行します

mc mirror backup-minio/ new-minio/

クラスタ環境のリカバリガイドラインは以下の通りです:

災害復旧コピーが存在する場合、プライマリ-スタンバイスイッチ計画に従って復旧を実行します
コールドバックアップを使用する場合、オブジェクトストレージのデータディレクトリまたはイメージリポジトリの内容に従って復旧を実行します

6.3 実行手順

オブジェクトストレージを復元する前に、以下の事項を確認する必要があります:

復元対象のバケット範囲
リカバリポイント
オンラインオブジェクトを上書きするかどうか
対象ストレージパスと権限設定
ACCESS_DOMAIN リカバリ後のゲートウェイ設定

7. リカバリ後の確認

リカバリが完了した後、最低限以下を確認します:

データベースサービスの状態が正常であること
オブジェクトストレージサービスの状態が正常であること
管理者パネルを通じて管理可能であること
ユーザーログインが正常であること
コアドキュメントが作成、編集、保存、インポート、およびエクスポートできること
データ回復ポイントが予想通りであること

リカバリ完了後、以下の情報を記録します:

復元実行時間
データ回復時点
実行者、承認者、検査者
リカバリ後に発見された問題