Backup e ripristino dei dati su CMX 10.5 e versioni successive
Sommario
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.
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).
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.
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
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
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.
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
20-Oct-2022 |
Aggiunto 3375 |
1.0 |
16-May-2019 |
Versione iniziale |
Feedback