Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Processo di backup

Creazione del bundle di backup

Eseguire il backup di un'installazione di alta disponibilità

Spostamento del bundle da CMX a un computer diverso

Eliminazione dell'archivio di backup da CMX

Ripristino del backup

Ulteriori informazioni

Limitazioni del processo di backup e ripristino

Differenza tra backup e snapshot della macchina virtuale

Introduzione

Questo documento descrive come eseguire il backup e ripristinare i dati della configurazione e del client su un Cisco CMX 10.5 e versioni successive

Prerequisiti

Requisiti

È necessaria una conoscenza generale di CMX.

Componenti usati

Tutti i test sono stati eseguiti su un CMX 10.6.0-177 in esecuzione su un accessorio MSE 3375, MacOS 10.4 e Windows 10 ottobre 2018.

Ciò include CMX installato su un accessorio fisico 3365/3375 e su una macchina virtuale. È possibile eseguire il backup di questi componenti di CMX:

- Database: memorizza i dati di configurazione, ad esempio mappe, controller, posizione e dati di analisi aggregati

- Cache - Memorizza le visite ripetute di analisi

- Cassandra - Memorizza i dati di cronologia della posizione e le visite non elaborate di analisi

- Influxdb - Memorizza i dati delle metriche per i sistemi (non inclusi per impostazione predefinita)

- Console - Memorizza le configurazioni Console

- Mappe base - Memorizza le immagini della base per la visualizzazione dell'interfaccia utente

- Licenze - Memorizza le informazioni sulle licenze Cisco CMX

- Configurazione - Memorizza i dati di configurazione CMX

- Connectimages - Archivia immagini sul portale Connect Captive

- Conf - Memorizza la configurazione del nodo

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Processo di backup

Creazione del bundle di backup

Il backup di CMX, indipendentemente dalla posizione in cui è installato, può essere eseguito utilizzando un comando cmxos backup. Per impostazione predefinita, il backup include database, cache, cassandra, floormap, licenze, installazione, connectimages e configurazione. Aggiungete il parametro —all per includere anche i dati Influxdb. Per impostazione predefinita, il processo di backup arresta i servizi CMX durante l'esecuzione. Aggiungere il parametro —online per eseguire il backup senza arrestare i servizi CMX. Viene richiesto di immettere la directory in cui salvare l'archivio di backup tar.gz. La directory deve disporre delle autorizzazioni di lettura, scrittura ed esecuzione. Si consiglia di utilizzare la directory /tmp predefinita.

Su un CMX appena installato, il processo di backup richiede circa 30 secondi. Su un CMX completamente caricato e utilizzato, la creazione del bundle di backup può richiedere fino a un'ora.

Abilitare i messaggi keepalive nel client SSH in modo che non si verifichi un timeout della sessione durante la creazione del backup. In PuTTY, è possibile eseguire questa operazione nella scheda "Connessione":

[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]

Al termine dell'output, viene specificato il nome dell'archivio di backup:

[22:40:07] Done Backup. Created backup file /tmp/cmx_backup_mse33752_2019_04_28_22_39.tar.gz

Eseguire il backup di un'installazione di alta disponibilità

Se l'opzione Alta disponibilità è attiva e in esecuzione, poiché tutti i database sono sincronizzati tra il database primario e quello secondario, è sufficiente eseguire il backup dal CMX primario per salvare tutti i dati del client. È sufficiente eseguire il comando cmxos backup —all —online e trasferire i file dal server principale.

Se l'elevata disponibilità non è attualmente stabilita tra il server principale e quello secondario, determinare innanzitutto quali dati CMX sono stati completati e più recenti e creare un backup.

Nota: se è stata impostata la disponibilità elevata, il backup in linea è supportato solo sul server principale. Se l'opzione Alta disponibilità è disabilitata, i backup online e offline sono supportati sia sul server principale che su quello secondario.

Spostamento del bundle da CMX a un computer diverso

Se accade qualcosa al disco rigido del CMX o i file si danneggiano durante il processo di aggiornamento, i file di backup salvati sul CMX potrebbero andare persi. Si consiglia di spostare i dati da CMX a un altro computer utilizzando il protocollo SCP (Secure Copy Protocol). Di seguito potete trovare esempi su come farlo su Windows, MacOS e Linux PC:

Windows:

Il modo più semplice per eseguire questa operazione in Windows è tramite il programma WinSCP. Dopo l'installazione, immettere l'indirizzo IP e le credenziali dell'utente cmxadmin e stabilire la connessione SCP. Passare alla cartella in cui è stato salvato il backup, individuare il file di backup e trascinarlo nella posizione desiderata sul computer locale (finestra a sinistra).

Importante: a causa delle restrizioni di accesso alla directory principale in CMX 10.6.x, non è presente il comando cd utilizzato da WinSCP per spostarsi nelle directory. In questo caso, non è possibile utilizzare WinSCP. Contattare Cisco TAC per ottenere l'accesso alla patch radice o trovare un'utilità SCP alternativa.

MacOS e Linux:

MacOS e la maggior parte delle distribuzioni Linux vengono forniti con un client SCP nativo. I file possono essere spostati con un semplice comando del terminale:

scp cmxadmin@<cmx_ip_address>:/<file_path_and_name_on_cmx> <file_path_and_name_on_local_machine>

Esempio:

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

In CMX viene richiesto di immettere le credenziali dell'utente cmxadmin, dopo di che i dati vengono trasferiti nella posizione specificata nel computer locale.

Nota: poiché CMX 10.5 e versioni successive è in esecuzione su CentOS 7, questo comando può essere utilizzato per spostare i dati da un CMX a uno appena installato. Poiché un controller wireless può essere sincronizzato solo con un CMX alla volta, accertarsi di arrestare il CMX da cui viene scaricato il bundle di backup.

Eliminazione dell'archivio di backup da CMX

In CMX versione 10.5.x, i file possono essere eliminati accedendo come utente root tramite il comando su, passando alla directory /tmp in cui sono stati salvati i file di backup ed eliminandola tramite il 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 partire dalla versione 10.6.0, l'accesso alla directory principale è stato limitato. Senza una patch speciale che può essere fornita solo da Cisco TAC, non è possibile eliminare i file come su 10.5. È possibile liberare spazio utilizzando il 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

Importante: se lo spazio non è ancora sufficiente per eseguire il backup dopo l'esecuzione di cmxos clean normal —delete, è necessario contattare Cisco TAC per accedere alla directory principale e rimuovere i file che occupano spazio.

Ripristino del backup

Se si desidera ripristinare il backup, trasferire il file di backup dal computer remoto a CMX. In Windows, è sufficiente trascinare e rilasciare i file utilizzando WinSCP. Su MacOS e Linux, utilizzare questo comando:

$ scp <file_path_and_name_on_local_machine> cmxadmin@<cmx_ip_address>:/tmp

Esempio:

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

Importante: il ripristino dei dati Cisco CMX deve essere eseguito da un dispositivo che abbia la stessa ora locale. In caso contrario, non sarà possibile accedere correttamente ai dati di analisi. Inoltre, i dati restituiscono errori o valori pari a zero nei report.

Per ripristinare i dati, CMX deve disporre di spazio libero su disco pari a 4 volte le dimensioni del bundle di backup. Se lo spazio disponibile non è sufficiente, è possibile provare ad aumentare lo spazio della macchina virtuale oppure eseguire il comando cmxos clean normal —delete. Il processo di ripristino può essere avviato utilizzando il comando cmxos restore. Aggiungendo il parametro -i, è possibile eseguire il backup solo di alcuni elementi (database, cache, cassandra, floormap, licenze, setup, conf). Consigliato per l'esecuzione di backup completi.

Il processo di ripristino richiede l'arresto di tutti i servizi. Assicurati di preparare una finestra di manutenzione abbastanza grande per questo processo perché può richiedere oltre un'ora.

[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  ]

Ulteriori informazioni

Limitazioni del processo di backup e ripristino

- I backup da CMX 10.3 o versione precedente non possono essere importati in CMX 10.5.x e versione successiva. I backup da 10.5.x possono essere importati in CMX 10.6.x

- Per garantire la conformità con GDPR, è necessario eseguire il backup di database, mappe di base, licenze e componenti di configurazione

- Verificare che la porta 22 non sia bloccata tra CMX e il computer utilizzato per accedervi

- Se si ripristinano i backup da un tipo diverso di distribuzione CMX, fare riferimento alla tabella per verificare se sono compatibili:

Ripristina...

Ripristina in...

Consigli

Stesse specifiche

Stesse specifiche

OK

Cisco MSE 3365 appliance

appliance Cisco 3375

OK

Cisco MSE 3365 appliance

vMSE (High-end MSE Virtual)

OK

vMSE high-end

Appliance Cisco 3375 e Cisco MSE 3365

OK, a meno che il computer di fascia alta non abbia più RAM allocata rispetto alle specifiche consigliate

vMSE standard

Appliance Cisco 3375 e Cisco MSE 3365

OK

vMSE standard

vMSE high-end

OK

vMSE di fascia bassa

Appliance Cisco 3375 e Cisco MSE 3365

OK

vMSE di fascia bassa

vMSE high-end

OK

vMSE di fascia bassa

vMSE standard

OK

appliance Cisco 3375

Cisco MSE 3365 appliance

Non consigliato

Cisco MSE 3365 appliance

vMSE standard

Non consigliato

Cisco MSE 3365 appliance

vMSE di fascia bassa

Non consigliato

vMSE high-end

vMSE standard

Non consigliato

vMSE high-end

vMSE di fascia bassa

Non consigliato

vMSE standard

vMSE di fascia bassa

Non consigliato

Differenza tra backup e snapshot della macchina virtuale

Gli snapshot della macchina virtuale non possono essere considerati uno strumento di backup in quanto non consentono di preservare l'integrità del file VMDK utilizzato dalla macchina virtuale per l'archiviazione dei dati.

Le istantanee funzionano "congelando" il file di archiviazione VMDK originale e creando ulteriori file di istantanee che acquisiscono le modifiche apportate al file VMDK originale (la cosiddetta catena di dischi). In questo modo lo stato del file del disco può essere mantenuto in tempo e ripristinato, se necessario, dopo aver apportato alcune modifiche.

Pertanto, se il file VMDK originale (padre) viene perso o è danneggiato in qualche modo, i dati dello snapshot non possono essere utilizzati per ripristinarne lo stato precedente e i dati archiviati vengono effettivamente persi.

Le best practice VMware per l'utilizzo di snapshot nell'ambiente vSphere indicano quanto segue:

- Non utilizzare snapshot come backup (motivi indicati)

- VMware consiglia di non utilizzare una singola istantanea per più di 72 ore (le dimensioni del file della istantanea continuano a crescere se conservato per un periodo più lungo). Ciò può causare l'esaurimento dello spazio disponibile nel percorso di archiviazione delle copie istantanee e influire sulle prestazioni del sistema.

- In una catena sono supportati al massimo 32 snapshot. Tuttavia, per ottenere prestazioni migliori, limitate l'uso di sole 2-3 istantanee.

Per ulteriori informazioni, consultare l'articolo sulle procedure ottimali per le copie istantanee di VMware.