Backup är inte en av de trendiga teknikerna som ropas om från varje strykjärn. Det måste bara vara i vilket seriöst företag som helst, det är allt. Vi säkerhetskopierar flera tusen servrar i vår bank - det här är ett komplext, intressant jobb, vars vissa finesser, såväl som typiska missuppfattningar om säkerhetskopiering, bara vill få veta.
Jag har arbetat med detta ämne i nästan 20 år, varav de senaste 2 åren har varit på Promsvyazbank. I början av träningen gjorde jag säkerhetskopior nästan manuellt, med skript som helt enkelt kopierade filer. Sedan dök det upp praktiska verktyg i Windows: Robocopy-verktyget för att förbereda filer och NT Backup för kopiering. Och först då kom tiden för specialiserad programvara, främst Veritas Backup Exec, som numera heter Symantec Backup Exec. Så jag har varit bekant med säkerhetskopior länge.
Enkelt uttryckt är säkerhetskopiering att behålla en kopia av data (virtuella maskiner, applikationer, databaser och filer) i fall med en viss regelbundenhet. Varje fall visar sig vanligtvis som ett hårdvaru- eller logiskt fel och resulterar i dataförlust. Syftet med ett backupsystem är att minska förlusten av information. Ett hårdvarufel är till exempel ett fel på servern eller lagringen där databasen finns. Logisk - det här är förlusten eller förändringen av en del av data, inklusive på grund av den mänskliga faktorn: de raderade av misstag en tabell, en fil, startade ett snett skript för exekvering. Det finns också regulatoriska krav för att lagra en viss typ av information under en lång period, till exempel upp till flera år.
Den mest typiska användningen av säkerhetskopior är återställning av en sparad kopia av databaser för utplacering av olika testsystem, kloner för utvecklare.
Det finns några typiska myter kring säkerhetskopiering som borde skingras för länge sedan. Här är de mest kända av dem.
Myt 1. Säkerhetskopiering har länge bara varit en liten funktion i säkerhets- eller lagringssystem
Backupsystem är fortfarande en separat klass av lösningar och mycket oberoende. De har för mycket arbete att göra. Faktum är att de är den sista försvarslinjen när det kommer till dataintegritet. Så backup fungerar i sin egen takt, enligt sitt eget schema. En daglig rapport genereras för servrarna, det finns händelser som fungerar som triggers för övervakningssystemet.
Dessutom låter förebilden för åtkomst till säkerhetskopieringssystemet dig delegera en del av befogenheten till administratörer av målsystem att hantera säkerhetskopior.
Myt 2. När det finns en RAID behövs ingen backup längre.
Utan tvekan är RAID-arrayer och datareplikering ett bra sätt att skydda informationssystem från hårdvarufel, och om du har en standby-server kan du snabbt organisera bytet till den om huvudmaskinen skulle gå sönder.
Från de logiska felen som gjordes av användarna av systemet sparas inte redundans och replikering. Här är en reservserver för återskrivning - ja, den kan hjälpa till om ett fel upptäcks innan det synkroniserades. Och om ögonblicket missas? Endast en snabb säkerhetskopiering hjälper här. Om du vet att data ändrades igår kan du återställa systemet till i förrgår och extrahera nödvändiga data från det. Med tanke på att logiska fel är de vanligaste, förblir den gamla goda säkerhetskopian ett beprövat och nödvändigt verktyg.
Myt 3. En backup är något som görs en gång i månaden.
Säkerhetskopieringsfrekvensen är en konfigurerbar inställning som i första hand beror på dina systemkrav för säkerhetskopiering. Det är fullt möjligt att hitta data som nästan aldrig ändras och som inte är särskilt viktiga, deras förlust kommer inte att vara kritisk för företaget.
De kan verkligen säkerhetskopieras en gång i månaden och ännu mer sällan. Men mer kritisk data sparas oftare, beroende på RPO-indikatorn (Recovery Point Objective) som anger den tillåtna dataförlusten. Detta kan vara en gång i veckan, en gång om dagen eller till och med flera gånger i timmen. Vi har dessa transaktionsloggar från DBMS.
När system tas i kommersiell drift ska säkerhetskopieringsdokumentation godkännas som återspeglar huvudpunkterna, uppdateringsförfarandet, förfarandet för återställning av systemet, förfarandet för lagring av säkerhetskopior och liknande.
Myt 4. Antalet kopior växer ständigt och tar upp all allokerad plats helt.
Säkerhetskopieringar har en begränsad lagringstid. Det är till exempel meningslöst att lagra alla 365 dagliga säkerhetskopior under året. Som regel är det acceptabelt att behålla dagliga kopior i 2 veckor, varefter de ersätts med färska, och versionen som gjordes först i månaden förblir i långtidsförvaring. Den lagras i sin tur också under en viss tid - varje exemplar har en livstid.
Det finns skydd för dataförlust. Regeln gäller: innan en säkerhetskopia raderas måste nästa skapas. Därför kommer data inte att raderas om säkerhetskopieringen inte har slutförts, till exempel på grund av att servern inte är tillgänglig. Inte bara tidsramar respekteras, utan antalet kopior i uppsättningen kontrolleras också. Om systemet är designat för att ha två fullständiga säkerhetskopior, kommer det alltid att finnas två av dem, och den gamla kommer att raderas först när en ny tredje har skrivits. Så ökningen av volymen som ockuperas av säkerhetskopieringsarkivet är endast associerad med ökningen av mängden skyddad data och beror inte på tid.
Myt 5. Säkerhetskopieringen startade - allt hängde sig
Det är bättre att säga detta: om allt hänger, växer inte administratörens händer därifrån. Generellt sett beror prestandan för en säkerhetskopia på många faktorer. Till exempel om hastigheten på själva säkerhetskopieringssystemet: hur snabba är disklagringar, bandbibliotek. Från hastigheten på säkerhetskopieringssystemets servrar: om de har tid att bearbeta data, utföra komprimering och deduplicering. Och även på hastigheten på kommunikationslinjerna mellan klienten och servern.
Säkerhetskopieringen kan gå till en eller flera strömmar, beroende på om systemet som säkerhetskopieras stöder multithreading. Till exempel låter Oracle DBMS dig ge flera trådar, beroende på antalet tillgängliga processorer, tills överföringshastigheten når nätverkets bandbreddsgräns.
Om du försöker säkerhetskopiera ett stort antal trådar, så finns det en chans att överbelasta ett körande system, det kommer verkligen att börja sakta ner. Därför väljs det optimala antalet trådar för att säkerställa tillräcklig prestanda. Om till och med den minsta minskningen av prestanda är kritisk, finns det ett utmärkt alternativ när säkerhetskopieringen inte utförs från en stridsserver, utan från dess klon - standby i databasterminologi. Denna process startar inte det huvudsakliga arbetssystemet. Data kan hämtas genom fler strömmar, eftersom servern inte används för underhåll.
I stora organisationer skapas ett separat nätverk för backupsystemet så att backupen inte påverkar produktionen. Dessutom får trafik inte överföras via nätverket, utan via SAN.
Vi försöker fördela belastningen över tiden också. Säkerhetskopieringar görs mestadels under icke-arbetstid: på natten, på helgerna. Dessutom kör de inte alla samtidigt. Säkerhetskopiering av virtuella maskiner är ett specialfall. Processen har praktiskt taget ingen effekt på själva maskinens prestanda, så säkerhetskopieringen kan spridas över dagtid och inte skjuta upp allt på natten. Det finns många finesser, om du tar hänsyn till allt kommer säkerhetskopiering inte att påverka systemens prestanda.
Myt 6. Lanserade ett backupsystem - det är feltolerans för dig
Glöm aldrig att ett backupsystem är den sista försvarslinjen, vilket innebär att det borde finnas ytterligare fem system framför det som säkerställer kontinuitet, hög tillgänglighet och katastroftolerans för IT-infrastrukturen och företagens informationssystem.
Att hoppas att säkerhetskopieringen ska återställa all data och snabbt höja den fallna tjänsten är inte värt det. Dataförlust från ögonblicket för säkerhetskopiering till ögonblicket för fel är garanterad, och data kan laddas upp till en ny server i flera timmar (eller dagar, om du har tur). Därför är det vettigt att skapa fullfjädrade feltoleranta system utan att flytta allt till en backup.
Myt 7. Jag satte upp en backup en gång, kontrollerade att den fungerar. Det återstår bara att titta på loggarna
Detta är en av de mest skadliga myterna, vars falskhet du inser först under händelsen. Framgångsrika backuploggar är ingen garanti för att allt verkligen gick som det skulle. Det är viktigt att kontrollera om den sparade kopian är möjlig att installera i förväg. Det vill säga starta återställningsprocessen i en testmiljö och titta på resultatet.
Och lite om systemadministratörens arbete
I manuellt läge har ingen kopierat data på länge. Moderna SRK:er kan säkerhetskopiera nästan allt, du behöver bara ställa in det ordentligt. Om en ny server har lagts till, ställ in policyer: välj innehållet som ska säkerhetskopieras, ange lagringsalternativ och tillämpa schemat.
Samtidigt finns det fortfarande mycket arbete på grund av den omfattande flottan av servrar, inklusive databaser, e-postsystem, virtuella maskinkluster och filresurser både på Windows och Linux/Unix. Anställda som håller backupsystemet igång sitter inte sysslolösa.
Till ära av semestern vill jag önska alla administratörer starka nerver, klarhet i rörelser och oändligt utrymme för att lagra säkerhetskopior!
Källa: will.com