Validate データのバックアップ
この記事では、Validate データのバックアップと復旧について説明します。
MariaDB データベースのビルド情報や Lucene の欠陥データなど、プロジェクトのビルド中に生成されるすべてのデータは、projects_root ディレクトリに保存されます。データは、ユーザーがビルドをロードしたり、指摘を引用したり、設定や構成を変更したりすると、それに応じて頻繁に変更されます。projects_root ディレクトリをバックアップすれば、必要なときにすべての関連データを復元できるようになります。デフォルトの場所およびその他の考慮事項に関する情報については、「projects_root ディレクトリ」を参照してください。
Validate インストールディレクトリには、基本チェッカー構成ファイル、カスタムチェッカー、およびデータベース構成ファイルが含まれており、それらのファイルが変更、追加、または削除されるときに定期的にバックアップしておく必要があります。Validate インストールディレクトリ内の構成ファイルを変更した場合は、変更後にバックアップしてください。これらのファイルの例については、「お使いになる前に」を参照してください。
カスタムチェッカーを作成して展開した場合は、<server_install>/plugins ディレクトリをバックアップしてください。
統合ビルド解析の一部として、必要なすべてのデータをテーブルディレクトリから projects_root ディレクトリに Validate がコピーするので、テーブルディレクトリをバックアップする必要はありません。
お使いになる前に
Validate インストールフォルダーで実行されているすべてのサーバーで共有される Validate インストールディレクトリ内の構成設定とデータは、自動的にはバックアップされません。最終的にマシンを変更したり、Validate インストールを移行したりする場合は、Validate インストールフォルダーを手動でバックアップして、このデータを含めてください。このデータの例として、以下のようなものがあります。
configフォルダーとpluginsフォルダー内の変更されたコンパイラーの構成、設定、カスタムチェッカー。configフォルダー内のkwfilter.confファイルとkwmysql.iniファイル。- taxonomies フォルダー内のカスタム分類基準。
clientsフォルダー内のclients.jsonファイル。
データ保護のヒント
プロジェクトまたは Validate サーバーをバックアップする場合は、以下の予防措置を講じることをお勧めします。
- バックアップを潜在的なサーバー障害やシステム障害から保護するため、バックアップは作成元のサーバーとは別の安全な場所に保存してください。
- セキュリティリスク、意図しない変更、不正アクセスを最小限に抑えるため、バックアップを作成するときには、システムユーザーアカウントではなくサービスアカウントを使用してください。
- バックアップが改ざんされないようにするため、バックアップを保存する前にハッシュを作成し、そのハッシュを安全な場所に保管してください。バックアップを復元する準備ができたら、もう一度ハッシュを生成し、それが元のハッシュと一致していることを確かめて、バックアップが変更されていないことを確認します。
- バックアップを不正アクセスから保護するため、好みの方法を使用してバックアップフォルダーを暗号化してください。たとえば、パスワードで保護された場所にバックアップフォルダーを配置したり、バックアップフォルダーを直接パスワード保護したりします。
- すべてのデータが確実にキャプチャされるようにするため、カスタマイズされた構成ファイルとカスタムチェッカー (ホットバックアップを実行しても問題のない不揮発性データ) をバックアップしてください。
データが破損した場合はどうすればよいですか?
データ破損は、いつでも予告なしに発生する可能性があります。追加調査に使用できるように解析履歴を保存するため、破損したデータベースを必ず保存してください。それらのデータがない場合は、プロジェクト全体を再作成しなければならなくなる可能性があります。
将来のデータ破損を防ぐため、「どのくらいの頻度でデータをバックアップすればよいですか?」セクションの説明に従って定期的にデータをバックアップしてください。
どのくらいの頻度でデータをバックアップすればよいですか?
データは定期的にバックアップすることをお勧めします。頻度の選択範囲は、以下のようないくつかの要素に応じて、数日から数か月までに及ぶ可能性があります。
- 組織の基準。たとえば、バックアップの頻度やメンテナンスのスケジュールを決定するための既存の方針が組織にある場合があります。
- リスク許容度。たとえば、コンプライアンス認証のために解析結果を使用する大規模な組織では、比較的頻繁にバックアップをすることが必要になる場合があります。
バックアップ方法
以下の各セクションの説明と手順を読んで、どの方法が適切か判断することをお勧めします。
コールドバックアップ
それぞれのプロジェクトを個別にバックアップせずにサーバー全体をバックアップするには、コールドバックアップを使用することをお勧めします。
コールドバックアップでは、以下のことを確保するため、Validate サーバーを少しの間シャットダウンします。
- データのバックアップ前に、実行中のデータトランザクションが完了するようにする
- バックアップからの復元が一貫したものになるようにする
ホットバックアップ
ホットバックアップは、Validate サーバーが稼働中であり、ユーザーがシステムにログインしているときに実行されます。ダウンタイムを最小限に抑えられますが、バックアッププロセス中にユーザーが作業を続けると、データの損失や破損につながる可能性があります。正式にサポートされており、データの損失や破損を招かない唯一のホットバックアップ方法は「メソッド 1: サポートされているスクリプトを使用する」です。
ハイブリッドバックアップ
ハイブリッドバックアップでは、ホットバックアップの後にコールドバックアップが実行されます。そうすることで、データの一貫性を確保しながら、ダウンタイムを最小限に抑えることができます。
コールドバックアップの実行
-
カスタマイズされたすべての構成ファイルを <server_install>/config から個別にバックアップします。
- Validate サーバーを停止します。「通常のプロセスとして実行されているサーバーの停止」を参照してください。
- 通常の OS (またはバックアップ ユーティリティ) コマンドを使用して、projects_root ディレクトリ全体をバックアップ メディアにコピーします。
- Validate サーバーを起動します。「サーバーを通常のプロセスとして起動する」を参照してください。
コールドバックアップからの復元
- Validate サーバーを停止します。「通常のプロセスとして実行されているサーバーの停止」を参照してください。
- インストール全体が壊れて再インストールした場合、または準備段階で構成ファイルをすべてバックアップしてある場合は、新たにインストールした <server_install>/config ディレクトリにそれらのファイルをコピーします。
- 壊れた projects_root ディレクトリの内容を削除します。
- projects_root をバックアップメディアから projects_root の場所に復元します。
- Validate サーバーを起動します。「サーバーを通常のプロセスとして起動する」を参照してください。
ホットバックアップの実行
サーバーの稼働中にバックアップを実行するには、以下の方法を使用することができます。
方法 1: サポートされているスクリプトを使用する
ダウンタイムを最小限に抑えるため、サーバーを停止せずにサーバーとプロジェクトの情報をバックアップすることができます。後で、バックアップを新しいプロジェクトルートに復元することができます。
この方法は、「方法 2: kwprojcopy を使用する」と同様のものであり、以下のようなメリットもあります。
- ファイルの破損を防ぐため、バックアップアーカイブの作成中はプロジェクト情報がロックされます。
- サーバーの稼働を停止する必要はありません。
- ニーズに合わせてスクリプトをカスタマイズすることができます。たとえば、バックアップアーカイブを作成しながら好みのファイルコピーツールを実行することができます。
Python スクリプトを手動で実行するのではなく、ランチャー validate_backup とvalidate_restore を使用してスクリプトが自動的に実行されるようにしてください。ランチャーを利用すれば、スクリプトが仮想環境内で動作し、バンドルされている Python インストールを使用して、必要なあらゆる依存関係がインストールされるようになります。
ご使用のシステムに応じたコマンドを実行してください。
Windows でサポートされているスクリプトを使用する
以下のコマンドを実行します。
<Validate-installation>/bin/validate_backup.cmd # For backup <Validate-installation>/bin/validate_restore.cmd # For restore
Linux でサポートされているスクリプトを使用する
- 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 - 次に、以下のコマンドを実行します。
--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 アーキテクチャでスナップショットを作成するのにかかる時間を調べてください。
- Validate サーバーを停止します。
- 要件と手順に従って、VM イメージをバックアップします。
- Validate サーバーを起動します。
バックアップから復元するには、Validate サーバーを停止して、現在の VM イメージおよび/または projects_root ディレクトリを置き換えます。それから、Validate サーバーを起動して、復元を完了します。
ハイブリッドバックアップの実行
rsync を使用して、二重バックアップを実行することができます。Rsync では、ファイルをバイナリレベルで増分的にコピーすることができます。完全バックアップを実行した場合、次回の rsync では変更されたファイルのみがコピーされて、増分バックアップに必要な時間が短縮されます。
- Validate サーバーの稼働中に、ライブ projects_root で "rsync -a projects_root projects_root_backup" を実行します。
- Validate サーバーを停止します。
- "rsync -a --delete projects_root projects_root_backup" を実行して、変更されたファイルをコピーします。ファイルの量が少なくなるので、完了までにかかる時間も短くなるはずです。
- Validate サーバーを起動します。
バックアップから復元するには、Validate サーバーを停止して、現在の projects_root ディレクトリを、作成した projects_root_backup に置き換えます。それから、Validate サーバーを起動して、復元を完了します。