Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Back-upproces

De back-upbundel maken

Een back-up maken van een installatie met hoge beschikbaarheid

De bundel verplaatsen van CMX naar een andere machine

Het back-up-archief verwijderen uit CMX

De back-up herstellen

Aanvullende informatie

Beperkingen van het back-up- en herstelproces

Verschil tussen back-up en snapshot van virtuele machine

Inleiding

In dit document wordt beschreven hoe u back-ups kunt maken van configuratie- en clientgegevens op een Cisco CMX 10.5 en hoger

Voorwaarden

Vereisten

Er is algemene kennis van het CMX vereist.

Gebruikte componenten

Alle tests werden uitgevoerd op een CMX 10.6.0-177 met MSE 3375-applicatie, MacOS 10.4 en Windows 10 oktober 2018 update.

Dit omvat CMX geïnstalleerd op een fysiek 3365/3375 apparaat, evenals op een virtuele machine. Van deze CMX-componenten kan een back-up worden gemaakt:

- Database - slaat configuratiegegevens op, zoals kaarten, controllers, locatie en geaggregeerde analysegegevens

- Cache - Opslaat analytics herhaalde bezoeken

- Cassandra - Opslaat historische gegevens van de locatie en analyse ruwe bezoeken

- Influxdb - slaat metriekgegevens op voor systemen (niet standaard inbegrepen)

- Consul - Opslaan Consul-configuraties

- Floormaps - Opslaan vloerbeelden voor UI display

- Licenties - Hierop wordt informatie over Cisco CMX-licenties opgeslagen

- Setup - Slaat CMX setup-gegevens op

- Connectimages - Opslaat afbeeldingen op Connect Captive Portal

- Conf - Opslaat knoopconfiguratie

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Back-upproces

De back-upbundel maken

CMX, waar ook geïnstalleerd, kan worden back-up gemaakt met behulp van een cmxos back-up opdracht. Standaard bevat back-up database, cache, cassandra, floormaps, licenties, installatie, connectimages en configuratie. Voeg de —alle parameter toe om de Influxdb-gegevens ook op te nemen. Standaard stopt back-upproces CMX-services terwijl deze worden uitgevoerd. Voeg de parameter toe —online om de back-up te maken zonder de CMX-services te stoppen. U wordt gevraagd om de map in te voeren waarin u het back-up tar.gz-archief wilt opslaan. Directory moet lees-, schrijf- en uitvoerrechten hebben. Het wordt aanbevolen om de standaard /tmp directory te gebruiken.

Op een nieuw geïnstalleerde CMX duurt het back-upproces ~30 seconden. Op een volledig geladen en gebruikte CMX, kan de verwezenlijking van reservebundel tot een uur duren.

Zorg ervoor dat keepalive-berichten in uw SSH-client worden ingeschakeld, zodat de sessie geen time-out veroorzaakt terwijl er een back-up wordt gemaakt. In PuTTY kan dit onder het tabblad "Verbinding" worden gedaan:

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

Aan het einde van het uitvoerdocument wordt de naam van het back-uparchief gespecificeerd:

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

Een back-up maken van een installatie met hoge beschikbaarheid

Als de Hoge Beschikbaarheid momenteel in gebruik is, aangezien alle databases zijn gesynchroniseerd tussen primair en secundair, is het nemen van de back-up van primair CMX voldoende om alle clientgegevens op te slaan. Voer gewoon cmxos back-up —all —online commando en de bestanden van de primaire server.

Als er momenteel geen hoge beschikbaarheid is tussen de primaire en de secundaire server, moet u eerst bepalen welke CMX volledige en meest recente gegevens heeft en een back-up maken.

Opmerking: Als High Availability is ingesteld, wordt online back-up alleen op de primaire server ondersteund. Als High Availability is uitgeschakeld, worden online- en offline-back-ups ondersteund op zowel primaire als secundaire back-ups.

De bundel verplaatsen van CMX naar een andere machine

Als er iets gebeurt met de harde schijf van de CMX of bestanden worden beschadigd tijdens het upgradeproces, back-up bestanden opgeslagen op de CMX kan verloren gaan. Het wordt aanbevolen om de gegevens van CMX naar een andere machine te verplaatsen met behulp van Secure Copy Protocol (SCP). Hieronder vindt u voorbeelden hoe u dat kunt doen op Windows, MacOS en Linux PC:

Windows:

De eenvoudigste manier om dit op Windows te doen is via het WinSCP-programma. Na installatie, voer het IP-adres en de referenties van de cmxadmin-gebruiker in en stel de SCP-verbinding in. Navigeer naar de map waarin de back-up wordt opgeslagen, zoek het back-upbestand en sleep het naar de gewenste locatie op uw lokale computer (linkervenster).

Belangrijk: vanwege root access beperkingen in CMX 10.6.x, commando cd die WinSCP gebruikt om directories te navigeren is niet aanwezig. In deze situatie is het gebruik van WinSCP niet mogelijk. Neem contact op met Cisco TAC als u toegang wilt krijgen tot de basispatch of als u een alternatieve SCP-hulpprogramma wilt vinden.

MacOS en Linux:

MacOS en de meeste Linux-distributies worden geleverd met native scp-client. Bestanden kunnen worden verplaatst met een eenvoudige terminalopdracht:

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

Voorbeeld:

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 toont een prompt om de referenties van de cmxadmin gebruiker in te voeren, waarna de gegevens worden overgebracht naar de opgegeven locatie in uw lokale machine.

Opmerking: Aangezien CMX 10.5 en hoger wordt uitgevoerd op CentOS 7, kan deze opdracht worden gebruikt om de gegevens te verplaatsen van een CMX naar een nieuw geïnstalleerde. Aangezien één draadloze controller slechts met één CMX tegelijk kan worden gesynchroniseerd, moet u ervoor zorgen dat de CMX wordt afgesloten waar de back-upbundel wordt gedownload.

Het back-up-archief verwijderen uit CMX

In CMX versie 10.5.x, kunnen de bestanden worden verwijderd door in te loggen als root gebruiker via su commando, te navigeren naar de /tmp directory waar de back-up bestanden zijn opgeslagen en te verwijderen via rm -f commando:

[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

Vanaf versie 10.6.0 is de toegang tot de hoofdmap beperkt. Zonder speciale patch die alleen kan worden gegeven door Cisco TAC, is het verwijderen van de bestanden zoals op 10.5 niet mogelijk. Er kan wat ruimte vrijgemaakt worden door de cmxos clean normal —delete opdracht:

[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

Belangrijk: Als er nog niet genoeg ruimte is om de back-up uit te voeren na het uitvoeren van cmxos clean normal —delete —, moet u contact opnemen met Cisco TAC om toegang te krijgen tot root en bestanden te verwijderen die ruimte innemen.

De back-up herstellen

Als u de back-up wilt herstellen, zet u het back-upbestand over van de externe machine naar CMX. In vensters kunt u de bestanden eenvoudig slepen en neerzetten met WinSCP. Gebruik deze opdracht op MacOS en Linux:

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

Voorbeeld:

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

Belangrijk: de CMX-gegevens van Cisco moeten worden hersteld vanaf een apparaat met dezelfde lokale tijd. Anders hebt u geen juiste toegang tot de analysegegevens. Daarnaast resulteren de gegevens in fouten of nulwaarden op rapporten.

Om gegevens te herstellen, CMX moet vrije schijfruimte hebben 4 keer de grootte van de reservebundel. Als er niet genoeg ruimte is, kunt u proberen de ruimte van de VM te vergroten of door cmxos clean normal —delete opdracht verwijderen. Het herstelproces kan worden gestart met de opdracht cmxos Restore. Wanneer u de -i parameter toevoegt, kunt u alleen back-ups maken van bepaalde elementen (database, cache, cassandra, floormaps, licenties, setup, conf). Het wordt aanbevolen om volledige back-ups uit te voeren.

Herstelproces vereist dat alle services worden gestopt. Zorg ervoor dat u voldoende onderhoudsvenster voor dit proces voorbereidt, aangezien dit meer dan een uur kan duren.

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

Aanvullende informatie

Beperkingen van het back-up- en herstelproces

- Back-ups van CMX 10.3 of ouder kunnen niet worden geïmporteerd in CMX 10.5.x en hoger. Back-ups van 10.5.x kunnen worden geïmporteerd in CMX 10.6.x

- Om te voldoen aan de AVG moet een back-up van database, vloerkaarten, licenties en setup-componenten worden uitgevoerd

- Zorg ervoor dat poort 22 niet wordt geblokkeerd tussen CMX en de machine die wordt gebruikt om toegang te krijgen

- Als u back-ups van een ander type CMX-implementatie wilt herstellen, raadpleegt u de tabel om te controleren of deze compatibel zijn:

Terugzetten vanaf...

Terugzetten op...

Aanbevelingen

Dezelfde specificaties machine

Dezelfde specificaties machine

OK

Cisco MSE 3365 applicatie

Cisco 3375 applicatie

OK

Cisco MSE 3365 applicatie

High-end MSE virtueel (vMSE)

OK

High-end vMSE

Cisco 3375- en Cisco MSE 3365-apparaten

OK, tenzij de high-end machine meer RAM-geheugen heeft toegewezen dan de aanbevolen specificaties

Standaard vMSE

Cisco 3375- en Cisco MSE 3365-apparaten

OK

Standaard vMSE

High-end vMSE

OK

Low-end vMSE

Cisco 3375- en Cisco MSE 3365-apparaten

OK

Low-end vMSE

High-end vMSE

OK

Low-end vMSE

Standaard vMSE

OK

Cisco 3375 applicatie

Cisco MSE 3365 applicatie

Niet aanbevolen

Cisco MSE 3365 applicatie

Standaard vMSE

Niet aanbevolen

Cisco MSE 3365 applicatie

Low-end vMSE

Niet aanbevolen

High-end vMSE

Standaard vMSE

Niet aanbevolen

High-end vMSE

Low-end vMSE

Niet aanbevolen

Standaard vMSE

Low-end vMSE

Niet aanbevolen

Verschil tussen back-up en snapshot van virtuele machine

Virtual Machine-snapshots kunnen niet als een back-uptool worden beschouwd omdat ze niets doen om de integriteit van het VMDK-bestand te bewaren dat de Virtual Machine gebruikt voor de gegevensopslag.

Snapshots werken door het oorspronkelijke VMDK-opslagbestand te "bevriezen" en extra snapshot-bestanden te maken die de wijzigingen in het oorspronkelijke VMDK-bestand (de zogenaamde disk chain) opnemen. Op deze manier kan de status van het schijfbestand op tijd behouden blijven en indien nodig worden teruggedraaid nadat enkele wijzigingen zijn aangebracht.

Daarom, Als het originele (ouder) VMDK-bestand verloren is of op enige manier beschadigd is, kunnen momentopnamegegevens niet worden gebruikt om het terug te zetten naar de vorige staat en de opgeslagen gegevens zijn effectief verloren gegaan.

De best practices van VMware voor het gebruik van momentopnamen in de vSphere-omgeving vermelden het volgende:

- Maak geen gebruik van momentopnamen als back-ups (redenen omkleed)

- VMware raadt aan één snapshot niet langer dan 72 uur te gebruiken (het snapshot-bestand blijft groter worden wanneer het langer wordt bewaard. Hierdoor raakt de opslaglocatie voor de snapshot onvoldoende ruimte en zijn de systeemprestaties nadelig).

- Maximaal 32 snapshots worden ondersteund in een keten. Beperk het gebruik van slechts 2 tot 3 snapshots voor een betere prestatie.

Raadpleeg voor meer informatie het best practices-artikel over VMware-momentopnamen.