CMX 10.5以降でのデータのバックアップと復元
内容
概要
このドキュメントでは、Cisco CMX 10.5以降の設定およびクライアントデータをバックアップおよび復元する方法について説明します
前提条件
要件
CMXに関する一般的な知識が必要です。
使用するコンポーネント
すべてのテストは、MSE 3375アプライアンス、MacOS 10.4、およびWindows 10 2018年10月アップデートで動作するCMX 10.6.0-177で実行されました。
これには、物理3365/3375アプライアンスおよび仮想マシンにインストールされたCMXが含まれます。CMXの次のコンポーネントをバックアップできます。
- データベース：マップ、コントローラ、ロケーション、集約された分析データなどの設定データを保存します。
- キャッシュ：分析の繰り返しアクセスを保存
- Cassandra – ロケーション履歴データと分析の未加工の訪問を保存します。
- Influxdb – システムのメトリックデータを保存します（デフォルトでは含まれません）。
- Consul - Consulの設定を保存します。
- フロアマップ – UI表示用のフロアイメージを保存します。
- [ライセンス(Licenses)]:Cisco CMXライセンス情報を保存します
- Setup:CMX設定データを保存します。
- Connectimages:Connectキャプティブポータルにイメージを保存します。
- Conf：ノード設定を保存します。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
バックアッププロセス
バックアップバンドルの作成
CMXは、インストールされている場所に関係なく、cmxos backupコマンドを使用してバックアップできます。デフォルトでは、バックアップにはデータベース、キャッシュ、cassandra、フロアマップ、ライセンス、セットアップ、接続、および設定が含まれます。—allパラメータを追加して、Influxdbデータも含めます。デフォルトでは、バックアッププロセスは実行中のCMXサービスを停止します。パラメータ—onlineを追加して、CMXサービスを停止せずにバックアップを実行します。バックアップtar.gzアーカイブを保存するディレクトリを入力するよう求められます。ディレクトリには、読み取り、書き込み、および実行の権限が必要です。デフォルトの/tmpディレクトリを使用することをお勧めします。
新しくインストールされたCMXでは、バックアッププロセスに約30秒かかります。完全にロードされ使用されているCMXでは、バックアップバンドルの作成に最大1時間かかる場合があります。
バックアップの作成中にセッションがタイムアウトしないように、SSHクライアントでキープアライブメッセージを有効にしてください。PuTTYでは、これは[Connection]タブで実行できます。
[cmxadmin@mse33752 ~]$ cmxos backup --online --all Please enter the path for backup file [/tmp]: backup name: cmx_backup_mse33752_2019_04_28_22_39 backup dir: /tmp/cmx_backup_mse33752_2019_04_28_22_39 tar file: /tmp/cmx_backup_mse33752_2019_04_28_22_39.tar.gz running: sudo -u cmx /opt/cmx/bin/cmxctl version ---------------------------------------------------------------------- Build Version : 10.6.0-331 Build Time : 2019-01-24 13:27:35.937025 ---------------------------------------------------------------------- Image Version : 10.6.0-177 ---------------------------------------------------------------------- Preparing backup of following services: ['database', 'cache', 'cassandra', 'influxdb', 'floormaps', 'licenses', 'setup', 'connectimages', 'conf'] [22:39:56] Preparing for backup... Preparing for backup... Database size 51226723 Cache size 7794 Cassandra size 67462961 Floormaps size 1014394 Licenses size 6 Setup size 1912 Connectimages size 6 running: sudo -u cmx /opt/cmx/bin/cmxctl dump running locally Dumping configuration information... [localhost] Executing task 'dump_config_only' Done. . .
.
.
.
.
.
copy snapshot took 0.804718971252 seconds Backup Cassandra DB took: 8.50579595566 seconds [22:40:07] Backup InfluxDb... Backup InfluxDb... Backup Influx DB took: 0.0411479473114 seconds [22:40:07] Backup Floormaps... Backup Floormaps... Backup floor maps took: 0.055881023407 seconds [22:40:07] Backup licenses... Backup licenses... Backup licenses took: 0.000136137008667 seconds [22:40:07] Backup setup... Backup setup... Backup setup took: 0.00061297416687 seconds [22:40:07] Backup connect images... Backup connect images... Backup connect images took: 0.000127077102661 seconds [22:40:07] Backup node configuration... Backup node configuration... running: sudo -u cmx /opt/cmx/bin/cmxctl dump running locally Dumping configuration information... [localhost] Executing task 'dump_config_only' Done. Backup configuration took: 0.383893013 seconds [22:40:07] Creating tar file.. Creating tar file.. running: tar -chf /tmp/cmx_backup_mse33752_2019_04_28_22_39.tar.gz --use-compress-program=pigz -C /tmp cmx_backup_mse33752_2019_04_28_22_39 running: chmod a+rw /tmp/cmx_backup_mse33752_2019_04_28_22_39.tar.gz running: chown cmxadmin:cmxadmin /tmp/cmx_backup_mse33752_2019_04_28_22_39.tar.gz Post backup took: 0.17880988121 seconds Done Backup. Created backup file /tmp/cmx_backup_mse33752_2019_04_28_22_39.tar.gz [22:40:07] Done Backup. Created backup file /tmp/cmx_backup_mse33752_2019_04_28_22_39.tar.gz running: /opt/apache-cassandra-3.9/bin/nodetool --ssl -h cassandra.service.consul -p 7199 clearsnapshot Requested clearing snapshot(s) for [all keyspaces]
出力の最後に、バックアップアーカイブの名前が指定されます。
[22:40:07] Done Backup. Created backup file /tmp/cmx_backup_mse33752_2019_04_28_22_39.tar.gz
ハイアベイラビリティ設定のバックアップ
すべてのデータベースがプライマリとセカンダリの間で同期されるため、ハイアベイラビリティが現在稼働している場合は、プライマリCMXからバックアップを取得するだけで、すべてのクライアントデータを保存できます。cmxos backup —all —onlineコマンドを実行し、プライマリサーバからファイルを転送するだけです。
現在、プライマリとセカンダリのサーバ間でハイアベイラビリティが確立されていない場合は、最初にどのCMXに完全な最新のデータがあるかを判断し、そこからバックアップを作成します。
CMXから別のマシンへのバンドルの移動
CMXのハードドライブに何かが発生したり、アップグレードプロセス中にファイルが破損したりすると、CMXに保存されたバックアップファイルが失われる可能性があります。Secure Copy Protocol(SCP)を使用して、CMXから別のマシンにデータを移動することを推奨します。Windows、MacOS、およびLinux PCで実行する方法の例を次に示します。
Windows：
Windowsでこれを行う最も簡単な方法は、WinSCPプログラムを使用することです。インストール後、cmxadminユーザのIPアドレスとクレデンシャルを入力し、SCP接続を確立します。バックアップが保存されているフォルダに移動し、バックアップファイルを見つけて、ローカルマシン上の目的の場所（左側のウィンドウ）にドラッグします。
MacOSおよびLinux:
MacOSとほとんどのLinuxディストリビューションには、ネイティブのscpクライアントが付属しています。ファイルを移動するには、単純な端末コマンドを使用します。
scp cmxadmin@<cmx_ip_address>:/<file_path_and_name_on_cmx> <file_path_and_name_on_local_machine>
例：
VAPEROVI-M-H1YM:~ vaperovi$ scp cmxadmin@10.48.71.41:/tmp/cmx_backup_mse33752_2019_04_28_19_38.tar.gz /Users/vaperovi/cmx_backup_mse33752_2019_04_28_19_38.tar.gz cmxadmin@10.48.71.41's password: cmx_backup_mse33752_2019_04_28_19_38.tar.gz 100% 186KB 1.4MB/s 00:00
CMXは、cmxadminユーザのクレデンシャルを入力するプロンプトを表示します。この後、データはローカルマシン内の指定された場所に転送されます。
CMXからのバックアップアーカイブの削除
CMXバージョン10.5.xでは、suコマンドでrootユーザとしてログインし、バックアップファイルが保存されている/tmpディレクトリに移動してrm -f コマンドで削除することで、ファイルを削除できます。
[cmxadmin@mse33752 ~]$ su Password: [root@mse33752 cmxadmin]# [root@mse33752 cmxadmin]# cd /tmp [root@mse33752 tmp]# rm -f cmx_backup_mse33752_2019_04_28_19_38.tar.gz
バージョン10.6.0以降では、ルートアクセスが制限されています。Cisco TACのみが提供できる特別なパッチがない場合、10.5のようなファイルを削除することはできません。cmxos clean normal —deleteコマンドを使用すると、一部の領域を解放できます。
[cmxadmin@mse33752 ~]$ cmxos clean normal --delete Are you sure you wish to remove files? [y/N]: y Removing files in: /opt/cmx/var/log Remove: /opt/cmx/var/log/entropy.err Remove: /opt/cmx/var/log/backup.log.2 Remove: /opt/cmx/var/log/techsupport/cmx_tech_support_2019-04-28.log Removing files in: /opt/influxdb/shared Removing files in: /tmp
バックアップの復元
バックアップを復元する場合は、バックアップファイルをリモートマシンからCMXに転送します。Windowsでは、WinSCPを使用してファイルをドラッグアンドドロップするだけです。MacOSおよびLinuxでは、次のコマンドを使用します。
$ scp <file_path_and_name_on_local_machine> cmxadmin@<cmx_ip_address>:/tmp
例：
VAPEROVI-M-H1YM:~ vaperovi$ scp /Users/vaperovi/cmx_backup_mse33752_2019_04_28_19_38.tar.gz cmxadmin@10.48.71.41:/tmp cmxadmin@10.48.71.41's password: cmx_backup_mse33752_2019_04_28_19_38_copy.tar.gz 100% 186KB 1.3MB/s 00:00
データを復元するには、CMXにバックアップバンドルの4倍の空きディスク領域が必要です。十分なスペースがない場合は、VMのスペースを増やすか、cmxos clean normal —deleteコマンドを実行します。復元プロセスは、cmxos restoreコマンドを使用して開始できます。-iパラメータを追加すると、特定の要素(database、cache、cassandra、floormaps、licenses、setup、conf)のみをバックアップできます。完全バックアップを実行することをお勧めします。
復元プロセスでは、すべてのサービスを停止する必要があります。このプロセスには1時間以上かかることがあるため、十分に大きなメンテナンスウィンドウを準備してください。
[cmxadmin@mse33752 ~]$ cmxos restore Please enter the backup file path: /tmp/cmx_backup_mse33752_2019_04_28_22_39.tar.gz Please enter the path for untar backup file [/tmp]: Stopping monit (via systemctl): [ OK ] [23:49:19] Preparing for restore... Restore size 30383753 Available disk space in /tmp is 1812541169664 Available disk space is 1817753817088 [23:49:19] Untarring backup file... Backing up existing licenses on the system... Successfully saved existing licenses Stopping all services... Pre restore took: 41.672647953 seconds [23:50:00] Restoring Database... Created temporary database temp_mse Running command /usr/bin/sudo -u postgres pg_restore -j 8 -d temp_mse -Fc /tmp/cmx_backup_mse33752_2019_04_28_22_39/postgres/mse.dump Restored temporary database temp_mse Dropping database mse Renaming database temp_mse to mse Restarting database... Starting database... Restore database took: 10.2765719891 seconds [23:50:11] Restoring Cache... Stopping cache_6378... Restarting cache_6378... Stopping cache_6379... Restarting cache_6379... Stopping cache_6385... Restarting cache_6385... Stopping cache_6380... Restarting cache_6380... Stopping cache_6381... Restarting cache_6381... Stopping cache_6382... Restarting cache_6382... Stopping cache_6383... Restarting cache_6383... Stopping cache_6384... Restarting cache_6384... Restore Cache took: 61.1865711212 seconds [23:51:12] Restoring Cassandra... Stopping Cassandra... Starting Cassandra after wipe... starting cassandra Creating empty cassandra schemas Stopping Cassandra... Starting Cassandra after restore ... starting cassandra Restore Cassandra took: 117.123826981 seconds [23:53:09] Restoring floormaps... Restore floor maps took: 0.0736980438232 seconds [23:53:09] Restoring licenses... Restore licenses took: 0.000176906585693 seconds [23:53:09] Restoring setup... Restore setup took: 0.00758194923401 seconds [23:53:09] Restoring connect images... Restore connect images took: 0.000188827514648 seconds [23:53:09] Running Post Restore Tasks... [23:53:09] Migrating Schemas... [23:53:10] Migrating Cassandra Schemas... stopping cassandra Local licenses wont be retained. Running full vacuum command on postgres Performing cleanup of redis cache 6378 and 6383 to evict bloom filter stale entries. Performing cleanup of redis cache 6378 to evict stale records by qlesspyworker. Update CMX default certificate Post restore took: 61.7358779907 seconds [23:54:11] Starting all services... [23:56:04] Done Starting monit (via systemctl): [ OK ]
追加情報
バックアップおよび復元プロセスの制限
- CMX 10.3以前のバージョンからのバックアップは、CMX 10.5.x以降にインポートできません。10.5.xからのバックアップはCMX 10.6.xにインポートできます
- GDPRへの準拠を維持するには、データベース、フロアマップ、ライセンス、セットアップコンポーネントのバックアップを実行する必要があります
- CMXと、CMXへのアクセスに使用されるマシンとの間で、ポート22がブロックされていないことを確認します
- 別のタイプのCMX導入からバックアップを復元する場合は、次の表を参照して互換性があるかどうかを確認してください。
|
復元元…
|
復元先…
|
推奨事項
|
|---|---|---|
| 同じマシン仕様 |
同じマシン仕様 |
OK |
| Cisco MSE 3365アプライアンス |
Cisco 3375アプライアンス |
OK |
| Cisco MSE 3365アプライアンス |
ハイエンドMSE仮想(vMSE) |
OK |
| ハイエンドvMSE |
Cisco 3375およびCisco MSE 3365アプライアンス |
ハイエンドマシンに推奨される仕様よりも多くのRAMが割り当てられていない場合はOK |
| 標準vMSE |
Cisco 3375およびCisco MSE 3365アプライアンス |
OK |
| 標準vMSE |
ハイエンドvMSE |
OK |
| ローエンドvMSE |
Cisco 3375およびCisco MSE 3365アプライアンス |
OK |
| ローエンドvMSE |
ハイエンドvMSE |
OK |
| ローエンドvMSE |
標準vMSE |
OK |
| Cisco 3375アプライアンス |
Cisco MSE 3365アプライアンス |
非推奨 |
| Cisco MSE 3365アプライアンス |
標準vMSE |
非推奨 |
| Cisco MSE 3365アプライアンス |
ローエンドvMSE |
非推奨 |
| ハイエンドvMSE |
標準vMSE |
非推奨 |
| ハイエンドvMSE |
ローエンドvMSE |
非推奨 |
| 標準vMSE |
ローエンドvMSE |
非推奨 |
バックアップと仮想マシンスナップショットの違い
仮想マシンのスナップショットは、仮想マシンがデータストレージに使用するVMDKファイルの整合性を維持するために何も行わないため、バックアップツールと見なすことはできません。
スナップショットは、元のVMDKストレージ・ファイルを「凍結」し、元のVMDKファイルに加えられた変更をキャプチャする追加のスナップショット・ファイル（ディスク・チェーンと呼ばれます）を作成することによって動作します。これにより、ディスクファイルの状態を時間の経過に従って維持し、必要に応じて変更を加えた後にロールバックすることができます。
したがって、元の（親）VMDKファイルが失われたり、何らかの方法で破損したりした場合、スナップショットデータを使用して元の状態に復元することはできず、保存されたデータは実質的に失われます。
vSphere環境でスナップショットを使用するためのVMwareのベストプラクティスには、次の項目が記載されています。
- スナップショットをバックアップとして使用しない（理由を概説）
- VMwareでは、1つのスナップショットを72時間を超えて使用しないことをお勧めします（スナップショット・ファイルは、より長い期間保持されるとサイズが増大し続けます）。これにより、スナップショットの保存場所の領域が不足し、システムのパフォーマンスに影響を与える可能性があります)。
- 1つのチェーンで最大32個のスナップショットがサポートされます。ただし、パフォーマンスを向上させるには、使用するスナップショットを2 ～ 3つに制限します。
詳細については、VMwareスナップショットのベストプラクティスの記事を参照してください。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
2.0 |
20-Oct-2022 |
3375を追加 |
1.0 |
16-May-2019 |
初版 |
フィードバック