Backup e restauração de dados no CMX 10.5 e superior
Contents
Introduction
Este documento descreve como fazer backup e restaurar dados de configuração e do cliente em um Cisco CMX 10.5 e posterior
Prerequisites
Requirements
O conhecimento geral do CMX é obrigatório.
Componentes Utilizados
Todos os testes foram executados em um CMX 10.6.0-177 executado no dispositivo MSE 3375, MacOS 10.4 e atualização do Windows 10 de outubro de 2018.
Isso inclui o CMX instalado em um dispositivo 3365/3375 físico, bem como em uma máquina virtual. É possível fazer backup destes componentes do CMX:
- Banco de dados - Armazena dados de configuração, como mapas, controladores, localização e dados analíticos agregados
- Cache - armazena visitas de repetição de análise
- Cassandra - Armazena dados de histórico de localização e visitas brutas de análise
- Influxdb - Armazena dados de métricas para sistemas (não incluídos por padrão)
- Cônsul - Armazena configurações do Cônsul
- Floormaps - Armazena imagens do chão para exibição da interface do usuário
- Licenças - Armazena informações de licença do Cisco CMX
- Configuração - Armazena dados de configuração do CMX
- Connectimages - Armazena imagens no Connect Captive Portal
- Conf - Armazena a configuração do nó
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Processo de backup
Criando o pacote de backup
O CMX, independentemente de onde estiver instalado, pode ser copiado em backup usando um comando cmxos backup. Por padrão, o backup inclui banco de dados, cache, cassandra, mapas de piso, licenças, instalação, conectimages e configuração. Adicione o parâmetro —all para incluir também os dados Influxdb. Por padrão, o processo de backup interrompe os serviços de CMX durante a execução. Adicione o parâmetro —online para executar o backup sem parar os serviços CMX. Você será solicitado a digitar o diretório onde deseja salvar o arquivo tar.gz de backup. O diretório precisa ter permissões de leitura, gravação e execução. É recomendável usar o diretório /tmp padrão.
Em um CMX recém-instalado, o processo de backup leva aproximadamente 30 segundos. Em um CMX totalmente carregado e utilizado, a criação do pacote de backup pode levar até uma hora.
Certifique-se de habilitar as mensagens de keepalive em seu cliente SSH para que a sessão não exceda o tempo limite enquanto o backup está sendo criado. No PuTTY, isso pode ser feito na guia "Conexão":
[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]
No final da saída, o nome do arquivo de backup é especificado:
[22:40:07] Done Backup. Created backup file /tmp/cmx_backup_mse33752_2019_04_28_22_39.tar.gz
Fazendo backup de uma configuração de alta disponibilidade
Se a Alta disponibilidade estiver atualmente ativa e em execução, já que todos os bancos de dados são sincronizados entre o primário e o secundário, o backup do CMX primário é suficiente para salvar todos os dados do cliente. Basta executar o comando cmxos backup —all —online e transferir os arquivos do servidor primário.
Se a alta disponibilidade não estiver estabelecida atualmente entre os servidores primário e secundário, primeiro determine qual CMX tem dados completos e mais recentes e crie um backup a partir dele.
Movendo o pacote do CMX para uma máquina diferente
Se algo acontecer com o disco rígido do CMX ou os arquivos forem corrompidos durante o processo de atualização, os arquivos de backup salvos no CMX poderão ser perdidos. É recomendável mover os dados do CMX para outra máquina usando o protocolo SCP (Secure Copy Protocol). Abaixo, você pode encontrar exemplos de como fazer isso no Windows, MacOS e Linux PC:
Windows:
A maneira mais fácil de fazer isso no Windows é através do programa WinSCP. Após a instalação, insira o endereço IP e as credenciais do usuário cmxadmin e estabeleça a conexão SCP. Navegue até a pasta onde o backup foi salvo, localize o arquivo de backup e arraste-o para o local desejado na máquina local (janela esquerda).
MacOS e Linux:
O MacOS e a maioria das distribuições Linux vêm com o cliente scp nativo. Os arquivos podem ser movidos usando um comando de terminal simples:
scp cmxadmin@<cmx_ip_address>:/<file_path_and_name_on_cmx> <file_path_and_name_on_local_machine>
Exemplo:
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
O CMX mostra um prompt para inserir as credenciais do usuário cmxadmin, após o qual os dados são transferidos para o local especificado na sua máquina local.
Excluindo o arquivo de backup do CMX
No CMX versão 10.5.x, os arquivos podem ser excluídos efetuando login como usuário raiz através do comando su, navegando para o diretório /tmp onde os arquivos de backup foram salvos e excluindo-os através do comando 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
A partir da versão 10.6.0, o acesso à raiz foi restrito. Sem um patch especial que só possa ser fornecido pelo Cisco TAC, não é possível excluir os arquivos como no 10.5. Algum espaço pode ser liberado usando o comando 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
Restaurando o backup
Se desejar restaurar o backup, transfira o arquivo de backup da máquina remota para o CMX. No Windows, você pode simplesmente arrastar e soltar os arquivos usando o WinSCP. No MacOS e no Linux, use este comando:
$ scp <file_path_and_name_on_local_machine> cmxadmin@<cmx_ip_address>:/tmp
Exemplo:
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
Para restaurar dados, o CMX precisa ter espaço livre em disco 4 vezes maior que o tamanho do pacote de backup. Se não houver espaço suficiente, você pode tentar aumentar o espaço da VM ou executar o comando cmxos clean normal —delete. O processo de restauração pode ser iniciado usando o comando cmxos restore. Adicionando o parâmetro -i, você pode fazer backup somente de determinados elementos (database, cache, cassandra, floormaps, licenses, setup, conf). Recomenda-se a realização de backups completos.
O processo de restauração requer que todos os serviços sejam interrompidos. Certifique-se de preparar uma janela de manutenção suficientemente grande para este processo, pois ele pode levar mais de uma hora.
[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 ]
Additional Information
Restrições do processo de backup e restauração
- Backups de CMX 10.3 ou anterior não podem ser importados para CMX 10.5.x e posterior. Os backups de 10.5.x podem ser importados para o CMX 10.6.x
- Para manter a conformidade com o GDPR, é necessário realizar o backup do banco de dados, dos mapas de fábrica, das licenças e dos componentes de instalação
- Certifique-se de que a porta 22 não esteja bloqueada entre o CMX e a máquina que é usada para acessá-la
- Se estiver restaurando backups de um tipo diferente de implantação de CMX, consulte a tabela para verificar se eles são compatíveis:
|
Restaurar de...
|
Restaurar para...
|
Recomendações
|
|---|---|---|
| Mesmas especificações de máquina |
Mesmas especificações de máquina |
OK |
| Dispositivo Cisco MSE 3365 |
Dispositivo Cisco 3375 |
OK |
| Dispositivo Cisco MSE 3365 |
Virtual MSE de alto nível (vMSE) |
OK |
| vMSE high-end |
Dispositivos Cisco 3375 e Cisco MSE 3365 |
OK, a menos que a máquina avançada tenha mais RAM alocada do que as especificações recomendadas |
| vMSE padrão |
Dispositivos Cisco 3375 e Cisco MSE 3365 |
OK |
| vMSE padrão |
vMSE high-end |
OK |
| vMSE low-end |
Dispositivos Cisco 3375 e Cisco MSE 3365 |
OK |
| vMSE low-end |
vMSE high-end |
OK |
| vMSE low-end |
vMSE padrão |
OK |
| Dispositivo Cisco 3375 |
Dispositivo Cisco MSE 3365 |
Não recomendado |
| Dispositivo Cisco MSE 3365 |
vMSE padrão |
Não recomendado |
| Dispositivo Cisco MSE 3365 |
vMSE low-end |
Não recomendado |
| vMSE high-end |
vMSE padrão |
Não recomendado |
| vMSE high-end |
vMSE low-end |
Não recomendado |
| vMSE padrão |
vMSE low-end |
Não recomendado |
Diferença entre o backup e o instantâneo da máquina virtual
Os instantâneos de máquina virtual não podem ser considerados uma ferramenta de backup, pois não fazem nada para preservar a integridade do arquivo VMDK que a máquina virtual usa para seu armazenamento de dados.
Os snapshots operam "congelando" o arquivo de armazenamento VMDK original e criando arquivos de snapshot adicionais que capturam as alterações feitas no arquivo VMDK original (a chamada cadeia de discos). Dessa forma, o estado do arquivo de disco pode ser preservado no tempo e revertido para o, se necessário, depois que algumas alterações forem feitas.
Portanto, se o arquivo VMDK original (pai) for perdido ou for corrompido de alguma forma, os dados do instantâneo não poderão ser usados para restaurá-lo ao seu estado anterior e os dados armazenados serão efetivamente perdidos.
As práticas recomendadas da VMware para o uso de snapshots no ambiente vSphere mencionam o seguinte:
- Não use snapshots como backups (motivos descritos)
- A VMware recomenda não usar um único snapshot por mais de 72 horas (o arquivo de snapshot continua a aumentar de tamanho quando é mantido por um período mais longo. Isso pode fazer com que o local de armazenamento de snapshot fique sem espaço e afete o desempenho do sistema).
- Um máximo de 32 instantâneos é suportado em uma cadeia. No entanto, para obter um melhor desempenho, limite o uso de apenas 2 a 3 snapshots.
Para obter mais informações, consulte o artigo sobre práticas recomendadas para snapshots do VMware.
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
2.0 |
20-Oct-2022 |
3375 adicionado |
1.0 |
16-May-2019 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)