En katastrof orsakar vanligtvis ett avbrott, vilket innebär systemavbrott och potentiell förlust av data. När vi har upptäckt blackouten utlöser vi vår DR-plan för att återhämta oss från det. Men det skulle vara en överraskning, om det inte finns någon säkerhetskopia, eller efter långa timmars återställning, ser du att det inte är den du behöver.
Medan avbrott kan vara kostsamt – det finns ofta en ekonomisk påverkan som kan vara skadlig för verksamheten och dataförlust kan vara en anledning att stänga företaget.
För att minimera dataförlusten måste vi ha flera kopior av data på olika platser. Vi kan designa vår infrastruktur i olika lager och abstrahera varje lager från det under. Till exempel bygger vi ett lager för kluster av databasinstanser för att skydda mot maskinvarufel. Vi replikerar databaser över datacenter så att vi kan försvara oss mot ett datacenterfel. Varje ytterligare lager lägger till komplexitet, vilket kan bli en mardröm att hantera. Men fortfarande, i huvudsak, kommer en säkerhetskopia att ta den centrala platsen i katastrofåterställningen.
Det är därför det är viktigt att vara säker på att det är något vi kan lita på. Men hur ska man uppnå detta? Nåväl, ett av alternativen är att verifiera om säkerhetskopior har utförts baserat på de sista raderna av säkerhetskopieringsskript.
Ett enkelt exempel:
#!/bin/sh
mysqldump -h 192.168.1.1 -u user -ppassword dbname > filename.sql
if [ "$?" -eq 0 ]; then
echo "Success."
else
echo "Error."
fi
Men tänk om säkerhetskopieringsskriptet inte startade alls? Google erbjuder en hel del sökresultat för "Linux cron, körs inte."
Tyvärr erbjuder databaser med öppen källkod ofta inte säkerhetskopieringsarkiv.
Ännu en backup-testning. Du kanske har hört talas om Schrödingers katt. En känd Schrödingers säkerhetskopieringsteori är . "Tillståndet för en säkerhetskopia är okänt tills ett återställningsförsök görs." Låter som ett enkelt tillvägagångssätt men ett sådant försök skulle innebära att du måste ställa in en testmiljö, kopiera filer köra återställning ... efter varje säkerhetskopiering.
I den här artikeln kommer vi att se hur du kan använda ClusterControl för att se till att din säkerhetskopia exekveras för att uppnå Enterprise-Grade-databaser med Open Source-databaser.
Säkerhetskopieringsrapporter
ClusterControl har varit inriktat på driftsrapporter. Operational Reporting ger stöd till den dagliga verksamhetens övervakning och kontroll. Backuprapporten är en av många. Du kan hitta rapporter som:
- Daglig systemrapport
- Paketuppgraderingsrapport
- Schemaändringsrapport
- Tillgänglighet
- Säkerhetskopiering
Men varför skulle du behöva detta?
Du kanske redan har ett utmärkt övervakningsverktyg med alla möjliga mätvärden/grafer och du har förmodligen också ställt in varningar baserade på mätvärden och tröskelvärden (en del har till och med automatiska rådgivare som ger dem rekommendationer eller fixar saker automatiskt.) Det är bra - att ha insyn i din systemet är viktigt; ändå måste du kunna bearbeta mycket information.
Hur fungerar det här? ClusterControl samlar in information om säkerhetskopieringsprocessen, systemen, plattformarna och enheterna i säkerhetskopieringsinfrastrukturen när säkerhetskopieringsjobbet utlöses. All den informationen samlas ihop och lagras i en CMON (intern databas), så det finns inget behov av att fråga särskilda databaser ytterligare. Dessutom, när den upptäcker att du har ett körande kluster, men det inte fanns någon säkerhetskopia, kommer det också att rapporteras.
I rapportinformationen kan du spåra ett säkerhetskopierings-ID med detaljerad information om plats, storlek, tid och säkerhetskopieringsmetod. Mallar fungerar med data för olika databastyper, så när du hanterar din blandade miljö får du samma känsla och utseende. Det hjälper till att hantera olika databassäkerhetskopior bättre.
CLI-rapporter
För dem som föredrar kommandoradsgränssnittet, ett bra alternativ för att spåra säkerhetskopior ClusterControl Command Line Interface (CLI).
CLI låter dig utföra de flesta funktioner som är tillgängliga inom ClusterControl med enkla kommandon. Säkerhetskopiering och säkerhetskopieringsrapporter är en av dem.
Används i kombination med det kraftfulla GUI, det ger ClusterControl-användare alternativa sätt att hantera sina databasmiljöer med öppen källkod med vilken motor de föredrar.
$ s9s backup --list --cluster-id=1 --long --human-readable
ID CID STATE OWNER HOSTNAME CREATED SIZE FILENAME
1 1 COMPLETED dba 10.0.0.5 07:21:39 252K mysqldump_2017-05-09_072135_mysqldb.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:21:43 1014 mysqldump_2017-05-09_072135_schema.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:03 109M mysqldump_2017-05-09_072135_data.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:07 679 mysqldump_2017-05-09_072135_triggerseventsroutines.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:20 252K mysqldump_2017-05-09_073016_mysqldb.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:24 1014 mysqldump_2017-05-09_073016_schema.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:44 109M mysqldump_2017-05-09_073016_data.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:49 679 mysqldump_2017-05-09_073016_triggerseventsroutines.sql.gz
Från och med version 1.4.1 kommer installationsskriptet automatiskt att installera detta paket på ClusterControl-noden. CLI är en del av s9s-tools-paketet. Du kan också installera det separat på en annan dator för att fjärrstyra databasklustret. I likhet med ClusterControl använder den säker SSH-kommunikation.
Automatisk säkerhetskopiering
En säkerhetskopia är inte en säkerhetskopia om vi inte kan hämta data. Att verifiera säkerhetskopior är något som vanligtvis förbises av många företag. Låt oss se hur ClusterControl kan automatisera verifieringen av säkerhetskopior och hjälpa till att undvika överraskningar.
I ClusterControl, välj ditt kluster och gå till avsnittet "Säkerhetskopiering", välj sedan "Skapa säkerhetskopia".
Funktionen för automatisk verifiering av säkerhetskopiering är tillgänglig för schemalagda säkerhetskopieringar, så låt oss välja alternativet "Schemalägg säkerhetskopiering".
När vi schemalägger en säkerhetskopiering måste vi, förutom att välja de vanliga alternativen som metod eller lagring, även ange schema/frekvens. I det här exemplet ska vi ställa in MySQL-säkerhetskopiaverifiering. Detsamma kan dock uppnås för PostgreSQL- och Timescale-databaser.
När säkerhetskopieringsverifiering är markerad visas en annan flik.
Här kan vi ställa in alla nödvändiga steg för att förbereda miljön. När IP tillhandahålls är vi bra att gå och schemalägga sådan backup. Närhelst säkerhetskopieringen är klar kommer den att kopieras till en miljö för temporär säkerhetskopiering (alternativet "återställ säkerhetskopiering på"). Efter lyckad uppdatering kommer du att se status för verifiering på fliken för säkerhetskopiering.
Mislyckade säkerhetskopierings- och integrationstjänster
Ett annat intressant alternativ för att få fler ledtrådar om säkerhetskopiering är att använda ClusterControl Integration-tjänster. Du kan kontrollera körningsstatusen för säkerhetskopiering med tjänster från tredje part.
Integration med verktyg från tredje part gör att du kan automatisera varningar med andra populära system. För närvarande stöder ClusterControl ServiceNow, PagerDuty, VictorOps, OpsGenie, Slack, Telegram och Webhooks.
Nedan kan vi se ett exempel på Slack-kanalintegration. Närhelst en backup-händelse inträffar kommer den att visas i slack-kanalen.
Slutsats
Säkerhetskopiering är obligatoriskt i alla miljöer. De hjälper dig att skydda dina data och är i centrum för alla scenarier för katastrofåterställning. ClusterControl kan hjälpa till att automatisera säkerhetskopieringsprocessen för dina databaser och, i händelse av fel, återställa den med några få klick. Du kan också vara säker på att de körs framgångsrikt och tillförlitligt, så i händelse av en katastrof kommer du inte att förlora din data.