Det finns många säkerhetskopieringssystem, men vad ska man göra om servrarna som underhålls är utspridda över olika regioner och klienter och man behöver nöja sig med operativsystemverktyg?
God eftermiddag, Habr!
Mitt namn är Natalia. Jag är teamledare för applikationsadministratörsgruppen på NPO Krista. Vi är operativa för en grupp projekt i vårt företag. Vi har en ganska speciell situation: vi installerar och underhåller vår programvara både på vårt företags servrar och på servrar som finns hos kunder. Samtidigt finns det inget behov av att säkerhetskopiera hela servern. Endast "väsentlig data" är viktig: DBMS och enskilda kataloger i filsystemet. Naturligtvis har (eller har inte) kunderna sina egna säkerhetskopieringsregler och tillhandahåller ofta extern lagring för att lagra säkerhetskopior. I det här fallet, efter att ha skapat en säkerhetskopia, ser vi till att skicka till den externa lagringen.
Under en tid nöjde vi oss med ett bash-skript för säkerhetskopiering, men allt eftersom antalet konfigurationsalternativ växte, ökade komplexiteten i detta skript proportionellt, och vid ett tillfälle kom vi till behovet av att "förstöra det till grunden, och sedan...".
Färdiga lösningar var inte lämpliga av olika anledningar: behovet av att decentralisera säkerhetskopior, kravet att lagra säkerhetskopior lokalt på kundens plats, komplexiteten i installationen, importsubstitution och åtkomstbegränsningar.
Vi trodde att det skulle vara enklare att skriva något eget. Samtidigt ville vi få något som skulle räcka för vår situation under de kommande N åren, men med möjlighet till potentiell utökning av tillämpningsområdet.
Problemförhållandena var följande:
- Den grundläggande säkerhetskopieringsinstansen är autonom och körs lokalt
- lagring av säkerhetskopior och loggar alltid inom klientens nätverk
- instansen består av moduler – en sorts ”konstruktor”
- kompatibilitet med de distributioner som används krävs Linux, inklusive äldre, är potentiell plattformsoberoende kompatibilitet önskvärd
- SSH-åtkomst är tillräcklig för att fungera med instansen, det är inte nödvändigt att öppna ytterligare portar
- maximal enkel installation och användning
- Det är möjligt (men inte nödvändigt) att ha en separat instans som låter dig centralt se statusen för säkerhetskopior från olika servrar.
Det vi fick kan ses här:
Programvaran är skriven i Python3; körs på Debian, Ubuntu, CentOS, AstraLinux 1.6.
Dokumentationen finns publicerad i docs-katalogen i arkivet.
De viktigaste koncepten som systemet fungerar utifrån:
åtgärd – en åtgärd som implementerar en atomär operation (säkerhetskopiering av databas, säkerhetskopiering av katalog, överföring från katalog A till katalog B, etc.). Befintliga åtgärder finns i kärn-/åtgärdskatalogen.
uppgift – en uppgift, en uppsättning åtgärder som beskriver en logisk "säkerhetskopieringsuppgift"
schema – schema, en uppsättning uppgifter med en valfri indikation på uppgiftens körtid
Säkerhetskopieringskonfigurationen lagras i en yaml-fil; den allmänna strukturen för konfigurationen är:
- Allmänna Inställningar
- åtgärdsavsnitt: beskrivning av åtgärder som används på den här servern
- schemaavsnitt: beskrivning av alla uppgifter (åtgärdsuppsättningar) och schema för deras lansering av cron, om sådan lansering krävs
Vad applikationen kan göra just nu:
- De huvudsakliga operationerna vi stöder är: PostgreSQL-säkerhetskopiering via pg_dump, säkerhetskopiering av filsystemkataloger via tar; operationer med extern lagring; rsync mellan kataloger; säkerhetskopieringsrotation (radering av gamla kopior)
- anropa externt skript
- manuell utförande av en enskild uppgift
/opt/KristaBackup/KristaBackup.py run make_full_dump - du kan lägga till (eller ta bort) en separat uppgift eller hela schemat i crontaben
/opt/KristaBackup/KristaBackup.py enable all - Generera en triggerfil baserad på säkerhetskopieringsresultat. Den här funktionen är användbar tillsammans med Zabbix för att övervaka säkerhetskopior.
- kan arbeta i bakgrunden i webapi eller webbläge
/opt/KristaBackup/KristaBackup.py web start [--api]
Skillnaden mellan lägena: webapi har inget eget webbgränssnitt, men applikationen svarar på förfrågningar från en annan instans. Webbläget kräver installation av Flask och flera ytterligare paket, vilket inte alltid är acceptabelt, till exempel i certifierade Astra.Linux SE.
Webbgränssnittet låter dig se status och loggar för säkerhetskopior av anslutna servrar: "webbinstansen" begär data från "säkerhetskopieringsinstanserna" via API:et. Åtkomst till webben kräver auktorisering, åtkomst till webbapi:et gör det inte.
Loggar över felaktigt genomförda säkerhetskopior är markerade med färg: varning – gul, fel – röd.
Om administratören inte behöver ett fusklapp för parametrar och serveroperativsystemen är homogena kan du kompilera filen och distribuera det färdiga paketet.
Vi distribuerar det här verktyget huvudsakligen via Ansible, och lanserar det först till några av de minst viktiga servrarna, och efter testning till alla andra.
Resultatet är ett kompakt, autonomt kopieringsverktyg som kan automatiseras och är lämpligt att använda även av oerfarna administratörer. Det är bekvämt för oss – kanske det också är användbart för dig?
Källa: will.com
