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 - 시스템에 대한 메트릭 데이터 저장(기본적으로 포함되지 않음)
- Connist - Connist 컨피그레이션 저장
- Floormaps - UI 표시를 위한 바닥 이미지를 저장합니다.
- 라이센스 - Cisco CMX 라이센스 정보 저장
- Setup - CMX 설정 데이터를 저장합니다.
- Connectimages - Connect 종속 포털에 이미지 저장
- Conf - 노드 컨피그레이션을 저장합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
백업 프로세스
백업 번들 생성
CMX는 설치된 위치와 상관없이 cmxos backup 명령을 사용하여 백업할 수 있습니다. 기본적으로 백업에는 데이터베이스, 캐시, cassandra, floormaps, 라이센스, 설정, 연결, 컨피그레이션이 포함됩니다. Influxdb 데이터도 포함하려면 —all 매개변수를 추가합니다. 기본적으로 백업 프로세스는 수행되는 동안 CMX 서비스를 중지합니다. CMX 서비스를 중지하지 않고 백업을 수행하려면 온라인으로 매개변수를 추가합니다. 백업 tar.gz 아카이브를 저장할 디렉토리를 입력하라는 프롬프트가 표시됩니다. 디렉터리에 읽기, 쓰기 및 실행 권한이 있어야 합니다. 기본 /tmp 디렉토리를 사용하는 것이 좋습니다.
새로 설치된 CMX에서 백업 프로세스는 최대 30초가 소요됩니다. 완전히 로드되고 활용되는 CMX에서 백업 번들을 생성하는 데 최대 1시간이 걸릴 수 있습니다.
백업이 생성되는 동안 세션이 시간 초과되지 않도록 SSH 클라이언트에서 keepalive 메시지를 활성화해야 합니다. 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 백업 —all —online 명령을 실행하고 기본 서버에서 파일을 전송하기만 하면 됩니다.
현재 기본 서버와 보조 서버 간에 고가용성이 설정되지 않은 경우 먼저 어떤 CMX에 전체 및 최신 데이터가 있는지 확인하고 그로부터 백업을 생성합니다.
CMX에서 다른 시스템으로 번들 이동
업그레이드 프로세스 중에 CMX의 하드 드라이브에 문제가 발생하거나 파일이 손상된 경우 CMX에 저장된 백업 파일이 손실될 수 있습니다. SCP(Secure Copy Protocol)를 사용하여 CMX에서 다른 시스템으로 데이터를 이동하는 것이 좋습니다. 아래 Windows, MacOS 및 Linux PC에서 이 작업을 수행하는 방법에 대한 예를 찾을 수 있습니다.
창:
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 명령을 통해 루트 사용자로 로그인하고 백업 파일이 저장된 /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 매개변수를 추가하면 특정 요소(데이터베이스, 캐시, 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을 계속 준수하려면 데이터베이스, 플로어 맵, 라이센스 및 설정 구성 요소의 백업을 수행해야 합니다
- 포트 22가 CMX와 포트 22에 액세스하는 데 사용되는 시스템 사이에 차단되어 있지 않은지 확인합니다
- 다른 유형의 CMX 구축에서 백업을 복원하는 경우 다음 표를 참조하여 호환되는지 확인하십시오.
|
복원 원본...
|
복원 대상...
|
권장 사항
|
|---|---|---|
| 동일한 시스템 사양 |
동일한 시스템 사양 |
확인 |
| Cisco MSE 3365 어플라이언스 |
Cisco 3375 어플라이언스 |
확인 |
| Cisco MSE 3365 어플라이언스 |
하이엔드 MSE 가상(vMSE) |
확인 |
| 하이엔드 vMSE |
Cisco 3375 및 Cisco MSE 3365 어플라이언스 |
고급 시스템에 권장 사양보다 더 많은 RAM이 할당되지 않은 경우 확인 |
| 표준 vMSE |
Cisco 3375 및 Cisco MSE 3365 어플라이언스 |
확인 |
| 표준 vMSE |
하이엔드 vMSE |
확인 |
| 로우엔드 vMSE |
Cisco 3375 및 Cisco MSE 3365 어플라이언스 |
확인 |
| 로우엔드 vMSE |
하이엔드 vMSE |
확인 |
| 로우엔드 vMSE |
표준 vMSE |
확인 |
| 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에서는 72시간 이상 단일 스냅샷을 사용하지 않는 것이 좋습니다(스냅샷 파일은 더 오래 보존될 경우 크기가 계속 커집니다). 따라서 스냅샷 스토리지 위치에 공간이 부족해지고 시스템 성능이 저하될 수 있습니다.)
- 하나의 체인에서 최대 32개의 스냅샷이 지원됩니다. 그러나 더 나은 성능을 위해 스냅샷을 2~3개만 사용하도록 제한합니다.
자세한 내용은 VMware 스냅샷 모범 사례 문서를 참조하십시오.
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
2.0 |
20-Oct-2022 |
3375 추가 |
1.0 |
16-May-2019 |
최초 릴리스 |
피드백