Backup er ikke en af de trendy teknologier, der bliver råbt om fra hvert jern. Det skal bare være i ethvert seriøst selskab, det er alt. Vi sikkerhedskopierer flere tusinde servere i vores bank - dette er et komplekst, interessant job, hvor nogle af finesserne, såvel som typiske misforståelser om sikkerhedskopiering, bare gerne vil have besked.
Jeg har arbejdet med dette emne i næsten 20 år, hvoraf de sidste 2 år har været hos Promsvyazbank. Allerede i begyndelsen af øvelsen lavede jeg backups næsten manuelt med scripts, der blot kopierede filer. Så dukkede praktiske værktøjer op i Windows: Robocopy-værktøjet til at forberede filer og NT Backup til kopiering. Og først da kom tiden til specialiseret software, primært Veritas Backup Exec, som nu hedder Symantec Backup Exec. Så jeg har været bekendt med sikkerhedskopier i lang tid.
Enkelt sagt er sikkerhedskopiering at opbevare en kopi af data (virtuelle maskiner, applikationer, databaser og filer) bare i tilfælde af en vis regelmæssighed. Hvert tilfælde manifesterer sig normalt som en hardware- eller logisk fejl og resulterer i tab af data. Formålet med et backup-system er at reducere tab af information. En hardwarefejl er for eksempel en fejl på serveren eller lageret, hvor databasen er placeret. Logisk - dette er tab eller ændring af en del af dataene, herunder på grund af den menneskelige faktor: de ved et uheld slettede en tabel, en fil, lancerede et skævt script til udførelse. Der er også regulatorkrav til at opbevare en bestemt type information i en længere periode, for eksempel op til flere år.
Den mest typiske brug af sikkerhedskopier er gendannelse af en gemt kopi af databaser til implementering af forskellige testsystemer, kloner til udviklere.
Der er et par typiske myter omkring backup, som burde være aflivet for længe siden. Her er de mest berømte af dem.
Myte 1. Backup har længe kun været en lille funktion i sikkerheds- eller lagersystemer
Backupsystemer forbliver stadig en separat klasse af løsninger og meget uafhængige. De har for meget arbejde at gøre. Faktisk er de den sidste forsvarslinje, når det kommer til dataintegritet. Så backup fungerer i sit eget tempo, efter sin egen tidsplan. Der genereres en daglig rapport for serverne, der er hændelser, der fungerer som triggere for overvågningssystemet.
Derudover giver rollemodellen for adgang til backupsystemet dig mulighed for at delegere en del af beføjelsen til administratorer af målsystemer til at administrere sikkerhedskopier.
Myte 2. Når der er et RAID, er en backup ikke længere nødvendig.
Uden tvivl er RAID-arrays og datareplikering en god måde at beskytte informationssystemer mod hardwarefejl, og hvis du har en standby-server, kan du hurtigt organisere skift til den, hvis hovedmaskinen svigter.
Fra de logiske fejl, der blev lavet af brugerne af systemet, gemmer redundans og replikering ikke. Her er en tilbageskrivnings-standby-server - ja, den kan hjælpe, hvis der opdages en fejl, før den blev synkroniseret. Og hvis øjeblikket er forpasset? Kun en rettidig backup vil hjælpe her. Hvis du ved, at dataene ændrede sig i går, kan du gendanne systemet til i forgårs og udtrække de nødvendige data fra det. I betragtning af at logiske fejl er de mest almindelige, forbliver den gode gamle backup et gennemprøvet og nødvendigt værktøj.
Myte 3. En backup er noget, der laves en gang om måneden.
Sikkerhedskopieringsfrekvensen er en konfigurerbar indstilling, der primært afhænger af dine backupsystemkrav. Det er ganske muligt at finde data, der næsten aldrig ændrer sig og ikke er særligt vigtige, deres tab vil ikke være kritisk for virksomheden.
De kan faktisk sikkerhedskopieres en gang om måneden og endnu sjældnere. Men mere kritiske data gemmes oftere, afhængigt af RPO-indikatoren (Recovery point objrective), som angiver det tilladte datatab. Dette kan være en gang om ugen, en gang om dagen eller endda flere gange i timen. Vi har disse transaktionslogfiler fra DBMS.
Når systemer sættes i kommerciel drift, skal der godkendes backup-dokumentation, som afspejler hovedpunkterne, opdateringsproceduren, proceduren for retablering af systemet, proceduren for lagring af backups og lignende.
Myte 4. Mængden af kopier vokser konstant og optager enhver tildelt plads fuldstændigt.
Sikkerhedskopier har en begrænset opbevaringsperiode. Det giver for eksempel ingen mening at gemme alle 365 daglige backups i løbet af året. Som regel er det acceptabelt at opbevare daglige kopier i 2 uger, hvorefter de udskiftes med friske, og den version, der blev lavet først i måneden, forbliver i langtidsopbevaring. Det bliver til gengæld også gemt i et vist tidsrum – hver kopi har en levetid.
Der er beskyttelse mod tab af data. Reglen gælder: før en sikkerhedskopi slettes, skal den næste dannes. Derfor slettes dataene ikke, hvis sikkerhedskopieringen ikke er gennemført, for eksempel på grund af serverens utilgængelighed. Ikke kun tidsrammer respekteres, men antallet af kopier i sættet er også kontrolleret. Hvis systemet er designet til at have to fulde sikkerhedskopier, vil der altid være to af dem, og den gamle vil først blive slettet, når en ny tredje er skrevet. Så væksten i mængden optaget af backup-arkivet er kun forbundet med væksten i mængden af beskyttede data og afhænger ikke af tid.
Myte 5. Backup startede - alt hang
Det er bedre at sige dette: hvis alt hænger, vokser administratorens hænder ikke derfra. Generelt afhænger ydeevnen af en backup af mange faktorer. For eksempel om hastigheden af selve backup-systemet: hvor hurtige er disklagringer, båndbiblioteker. Fra hastigheden på backupsystemets servere: om de har tid til at behandle data, udføre komprimering og deduplikering. Og også på hastigheden af kommunikationslinjerne mellem klienten og serveren.
Sikkerhedskopieringen kan gå til en eller flere streams, afhængig af om systemet, der sikkerhedskopieres, understøtter multithreading. For eksempel giver Oracle DBMS dig mulighed for at give flere tråde, afhængigt af antallet af tilgængelige processorer, indtil overførselshastigheden rammer netværkets båndbreddegrænse.
Hvis du prøver at sikkerhedskopiere et stort antal tråde, så er der en chance for at overbelaste et kørende system, det vil virkelig begynde at bremse. Derfor vælges det optimale antal tråde for at sikre tilstrækkelig ydeevne. Hvis selv det mindste fald i ydeevnen er kritisk, er der en fremragende mulighed, når sikkerhedskopieringen ikke udføres fra en kampserver, men fra dens klon - standby i databaseterminologi. Denne proces starter ikke det primære arbejdssystem. Data kan hentes gennem flere streams, da serveren ikke bruges til vedligeholdelse.
I store organisationer oprettes et separat netværk til backupsystemet, så backupen ikke påvirker produktionen. Derudover må trafik ikke transmitteres gennem netværket, men gennem SAN.
Vi forsøger også at fordele belastningen over tid. Sikkerhedskopiering udføres for det meste uden for arbejdstiden: om natten, i weekenden. Desuden kører de ikke alle på samme tid. Sikkerhedskopier af virtuelle maskiner er et særligt tilfælde. Processen har praktisk talt ingen effekt på selve maskinens ydeevne, så sikkerhedskopieringen kan spredes over dagtimerne og ikke udskyde alt om natten. Der er mange finesser, hvis du tager alt i betragtning, vil backup ikke påvirke systemernes ydeevne.
Myte 6. Lancerede et backup-system - det er fejltolerance for dig
Glem aldrig, at et backup-system er den sidste forsvarslinje, hvilket betyder, at der bør være fem flere systemer foran det, der sikrer kontinuiteten, høj tilgængelighed og katastrofetolerance i it-infrastrukturen og virksomhedens informationssystemer.
At håbe på, at sikkerhedskopien vil gendanne alle data og hurtigt hæve den faldne tjeneste, er ikke det værd. Datatab fra sikkerhedskopieringsøjeblikket til fejlsøjeblikket er garanteret, og data kan uploades til en ny server i flere timer (eller dage, hvis du er heldig). Derfor giver det mening at skabe fuldgyldige fejltolerante systemer uden at flytte alt til en backup.
Myte 7. Jeg har oprettet en backup én gang, tjekket at den virker. Det er kun tilbage at se på logfilerne
Dette er en af de mest skadelige myter, hvis falskhed du først indser under hændelsen. Succesfulde backup-logfiler er ikke en garanti for, at alt virkelig gik, som det skulle. Det er vigtigt at kontrollere den gemte kopi for implementering på forhånd. Det vil sige start gendannelsesprocessen i et testmiljø og se på resultatet.
Og lidt om systemadministratorens arbejde
I manuel tilstand har ingen kopieret data i lang tid. Moderne SRK'er kan tage backup af næsten alt, du skal bare sætte det ordentligt op. Hvis en ny server er blevet tilføjet, skal du angive politikker: vælg det indhold, der skal sikkerhedskopieres, angiv lagerindstillinger, og anvend tidsplanen.
Samtidig er der stadig meget arbejde på grund af den omfattende flåde af servere, herunder databaser, mailsystemer, virtuelle maskinklynger og fildelinger både på Windows og Linux/Unix. Medarbejdere, der holder backupsystemet kørende, sidder ikke stille.
Til ære for ferien vil jeg gerne ønske alle administratorer stærke nerver, klare bevægelser og uendelig plads til opbevaring af sikkerhedskopier!
Kilde: www.habr.com