Validate データのバックアップ

この記事では、Validate データのバックアップと復旧について説明します。

MariaDB データベースのビルド情報や Lucene の欠陥データなど、プロジェクトのビルド中に生成されるすべてのデータは、projects_root ディレクトリに保存されます。データは、ユーザーがビルドをロードしたり、指摘を引用したり、設定や構成を変更したりすると、それに応じて頻繁に変更されます。projects_root ディレクトリをバックアップすれば、必要なときにすべての関連データを復元できるようになります。デフォルトの場所およびその他の考慮事項に関する情報については、「Projects_root ディレクトリ」を参照してください。

Validate インストールディレクトリには、基本チェッカー構成ファイル、カスタムチェッカー、およびデータベース構成ファイルが含まれており、それらのファイルが変更、追加、または削除されるときに定期的にバックアップしておく必要があります。Validate インストールディレクトリ内の構成ファイルを変更した場合は、変更後にバックアップしてください。これらのファイルの例については、「お使いになる前に」を参照してください。

カスタムチェッカーを作成して展開した場合は、<server_install>/plugins ディレクトリをバックアップしてください。

統合ビルド解析の一部として、必要なすべてのデータをテーブルディレクトリから projects_root ディレクトリに Validate がコピーするので、テーブルディレクトリをバックアップする必要はありません。

お使いになる前に

ホットバックアップからプロジェクトを復元するための手順に従わないと、不整合な状態になる可能性があります。

Validate インストールフォルダーで実行されているすべてのサーバーで共有される Validate インストールディレクトリ内の構成設定とデータは、自動的にはバックアップされません。最終的にマシンを変更したり、Validate インストールを移行したりする場合は、Validate インストールフォルダーを手動でバックアップして、このデータを含めてください。このデータの例として、以下のようなものがあります。

データ保護のヒント

プロジェクトまたは Validate サーバーをバックアップする場合は、以下の予防措置を講じることをお勧めします。

データが破損した場合はどうすればよいですか？ 

データ破損は、いつでも予告なしに発生する可能性があります。追加調査に使用できるように解析履歴を保存するため、破損したデータベースを必ず保存してください。それらのデータがない場合は、プロジェクト全体を再作成しなければならなくなる可能性があります。

将来のデータ破損を防ぐため、「どのくらいの頻度でデータをバックアップすればよいですか？」セクションの説明に従って定期的にデータをバックアップしてください。

どのくらいの頻度でデータをバックアップすればよいですか？

データは定期的にバックアップすることをお勧めします。頻度の選択範囲は、以下のようないくつかの要素に応じて、数日から数か月までに及ぶ可能性があります。

バックアップ方法

以下の各セクションの説明と手順を読んで、どの方法が適切か判断することをお勧めします。

コールドバックアップ

それぞれのプロジェクトを個別にバックアップせずにサーバー全体をバックアップするには、コールドバックアップを使用することをお勧めします。

コールドバックアップでは、以下のことを確保するため、Validate サーバーを少しの間シャットダウンします。

ホットバックアップ

ホットバックアップは、Validate サーバーが稼働中であり、ユーザーがシステムにログインしているときに実行されます。ダウンタイムを最小限に抑えられますが、バックアッププロセス中にユーザーが作業を続けると、データの損失や破損につながる可能性があります。正式にサポートされており、データの損失や破損を招かない唯一のホットバックアップ方法は「メソッド 1: サポートされているスクリプトを使用する」です。

ハイブリッドバックアップ

ハイブリッドバックアップでは、ホットバックアップの後にコールドバックアップが実行されます。そうすることで、データの一貫性を確保しながら、ダウンタイムを最小限に抑えることができます。

コールドバックアップの実行

Validate サーバーをシャットダウンする前に、サービスが一時的に利用できなくなることをユーザーに通知してください。

  1. カスタマイズされたすべての構成ファイルを <server_install>/config から個別にバックアップします。

  2. Validate サーバーを停止します。「通常のプロセスとして実行されているサーバーの停止」を参照してください。
  3. 通常の OS (またはバックアップ ユーティリティ) コマンドを使用して、projects_root ディレクトリ全体をバックアップ メディアにコピーします。
  4. Validate サーバーを起動します。「サーバーを通常のプロセスとして起動する」を参照してください。

コールドバックアップからの復元

最後に実行したコールドバックアップからデータが復元されるので、その最後のバックアップ以降に実行された解析とトランザクションが失われます。最後のバックアップにトランザクションを自動的に再適用することはできません。
  1. Validate サーバーを停止します。「通常のプロセスとして実行されているサーバーの停止」を参照してください。
  2. インストール全体が壊れて再インストールした場合、または準備段階で構成ファイルをすべてバックアップしてある場合は、新たにインストールした <server_install>/config ディレクトリにそれらのファイルをコピーします。
  3. 壊れた projects_root ディレクトリの内容を削除します。
  4. projects_root をバックアップメディアから projects_root の場所に復元します。
  5. Validate サーバーを起動します。「サーバーを通常のプロセスとして起動する」を参照してください。

ホットバックアップの実行

サーバーの稼働中にバックアップを実行するには、以下の方法を使用することができます。

方法 1: 「サポートされているスクリプトを使用する」は、後で復元可能なプロジェクトのホットバックアップを作成するためにサポートされている方法です。

方法 1: サポートされているスクリプトを使用する

この方法では、特定のプロジェクトに割り当てられたユーザーとグループの役割は復元されません。ただし、この方法では、サーバー情報を復元するときにユーザーとグループのグローバルな役割は復元されます。

ダウンタイムを最小限に抑えるため、サーバーを停止せずにサーバーとプロジェクトの情報をバックアップすることができます。後で、バックアップを新しいプロジェクトルートに復元することができます。

この方法は、「方法 2: kwprojcopy を使用する」と同様のものであり、以下のようなメリットもあります。

  • ファイルの破損を防ぐため、バックアップアーカイブの作成中はプロジェクト情報がロックされます。
  • サーバーの稼働を停止する必要はありません。
  • ニーズに合わせてスクリプトをカスタマイズすることができます。たとえば、バックアップアーカイブを作成しながら好みのファイルコピーツールを実行することができます。

Python スクリプトを手動で実行するのではなく、ランチャー validate_backup とvalidate_restore を使用してスクリプトが自動的に実行されるようにしてください。ランチャーを利用すれば、スクリプトが仮想環境内で動作し、バンドルされている Python インストールを使用して、必要なあらゆる依存関係がインストールされるようになります。

あるバージョンの validate_backup を使用して作成されたバックアップを異なるバージョンの validate_restore を使用して復元することはできません。たとえば、Validate 24.4 で作成されたバックアップは、Validate 24.3 または 25.1 を使用して復元することはできません。 プロジェクトまたはサーバーをバックアップおよび復元するには、同じバージョンの Validate を使用してください。新しいサーバーバージョンに移行する場合は、互換性の指摘を回避するため、移行が完了してから、新しいプロジェクトとサーバーのバックアップを作成することをお勧めします。

ご使用のシステムに応じたコマンドを実行してください。

Windows でサポートされているスクリプトを使用する

以下のコマンドを実行します。

<Validate-installation>/bin/validate_backup.cmd  # For backup
<Validate-installation>/bin/validate_restore.cmd  # For restore

Linux でサポートされているスクリプトを使用する

  1. Linux で backup.py と restore.py を実行するために必要なシステムライブラリをインストールして、ご使用の Linux ディストリビューションに合わせて調整しながら、以下のサンプルコマンドを実行します。
    curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash
    sudo apt-get install libmariadb3=1:11.5.2+maria~ubu2404 libmariadb-dev=1:11.5.2+maria~ubu2404
  2. 次に、以下のコマンドを実行します。
    3. コマンドでデータベースホストが適切に指定されていない場合、Linux でのスクリプトの実行時に MySQL の「ソケットエラー」が発生する可能性があります。回避策: スクリプトを正しい MySQL ホストに接続するには、コマンドに --db-host パラメーターを追加し、その後にデータベースが実行されているホストの完全修飾ドメイン名 (FQDN) または IP アドレスを指定してください。 例: backup --db-host 127.0.0.1
    <Validate-installation>/bin/validate_backup  # For backup
    <Validate-installation>/bin/validate_restore  # For restore

プロジェクトとサーバーのデータをバックアップ、復元、検証する

詳細な手順については、以下の記事を参照してください。

方法 2: kwprojcopy を使用する

この方法では、特定のプロジェクトに割り当てられたユーザーとグループの役割は復元されません。

kwprojcopy は、各プロジェクトを増分的にバックアップします。kwprojcopy はその実行中に、プロジェクトをロックし、プロジェクトのバックアップに必要なデータを収集します。後で kwprojcopy import 関数を使用してデータを復元することができます。

kwprojcopy を使用する場合、ダウンタイムは不要になりますが、プロジェクト固有のデータのみがバックアップされ、グローバルデータ (レポート定義など) はバックアップされません。

方法 3: 仮想マシン全体をバックアップする

仮想マシン (VM) バックアップを使用すると、サーバーをシャットダウンしながらバックアップ速度を上げることができます。この方法が実行可能かどうか判断するには、まず、さまざまな VM アーキテクチャでスナップショットを作成するのにかかる時間を調べてください。

  1. Validate サーバーを停止します。
  2. 要件と手順に従って、VM イメージをバックアップします。
  3. Validate サーバーを起動します。

バックアップから復元するには、Validate サーバーを停止して、現在の VM イメージおよび/または projects_root ディレクトリを置き換えます。それから、Validate サーバーを起動して、復元を完了します。

ハイブリッドバックアップの実行

rsync を使用して、二重バックアップを実行することができます。Rsync では、ファイルをバイナリレベルで増分的にコピーすることができます。完全バックアップを実行した場合、次回の rsync では変更されたファイルのみがコピーされて、増分バックアップに必要な時間が短縮されます。

  1. Validate サーバーの稼働中に、ライブ projects_root で "rsync -a projects_root projects_root_backup" を実行します。
  2. Validate サーバーを停止します。
  3. "rsync -a --delete projects_root projects_root_backup" を実行して、変更されたファイルをコピーします。ファイルの量が少なくなるので、完了までにかかる時間も短くなるはずです。
  4. Validate サーバーを起動します。

バックアップから復元するには、Validate サーバーを停止して、現在の projects_root ディレクトリを、作成した projects_root_backup に置き換えます。それから、Validate サーバーを起動して、復元を完了します。