1. februar 2012 kl. 00:33

Backup data i MySQL

• MySQL

Database backup er en ting, der altid skal konfigureres til allerede kørende projekter direkte på "live" produktionsservere.
Denne situation er let forklaret. Allerede i begyndelsen er ethvert projekt stadig tomt, og der er simpelthen ikke noget at kopiere. I den hurtige udviklingsfase er lederne af nogle få udviklere udelukkende beskæftiget med at skrue funktioner og dikkedarer ind, samt at rette kritiske fejl med en deadline på "i forgårs". Og først når projektet "starter", kommer erkendelsen af, at hovedværdien af ​​systemet er den akkumulerede database, og dets fiasko vil være en katastrofe.
Denne anmeldelsesartikel er for dem, hvis projekter allerede er nået hertil, men hanestegten endnu ikke har taget lokket.

1. Kopiering af databasefiler

MySQL-databasen kan kopieres, hvis du midlertidigt slukker for MySQL-serveren og blot kopierer filerne fra mappen /var/lib/mysql/db/. Hvis serveren ikke er slukket af åbenlyse årsager, er datatab og korruption sandsynlig. For store indlæste databaser er denne sandsynlighed tæt på 100%. Derudover, første gang du starter med en "beskidt" kopi af databasen, vil MySQL-serveren begynde processen med at tjekke hele databasen, hvilket kan tage timer.

I de fleste "live" projekter lukker man regelmæssigt for databaseserveren på lang tid uacceptabelt. For at løse dette problem bruges et trick baseret på snapshots filsystem. Et Snapshot er noget som et "foto" af et filsystem på bestemt øjeblik tid, gjort uden egentlig at kopiere data (og derfor hurtigt). Doven kopiering af objekter fungerer på lignende måde i mange moderne programmeringssprog.
Det generelle handlingsskema er som følger: alle tabeller er låst, databasefilens cache nulstilles, et øjebliksbillede af filsystemet tages, og tabellerne låses op. Herefter kopieres filerne stille og roligt fra snapshottet, hvorefter det destrueres. Den "blokerende" del af en sådan proces tager cirka sekunder, hvilket allerede er acceptabelt. Som en tilbagebetaling i nogen tid, mens øjebliksbilledet er "levende", falder ydeevnen af ​​filoperationer, hvilket primært påvirker hastigheden af ​​skriveoperationer til databasen.

Nogle filsystemer, såsom ZFS, understøtter at tage snapshots indbygget. Hvis du ikke bruger ZFS, men har en LVM volume manager på din server, kan du også kopiere MySQL databasen via snapshot. Endelig kan du under *nix bruge R1Soft Hot Copy snapshot-driveren, men denne metode virker ikke i openvz()-beholderen.

Til MyISAM-databaser er der et officielt gratis værktøj mysqlhotcopy, som "korrekt" kopierer MyISAM-databasefiler uden at stoppe serveren. Der er et lignende værktøj til InnoDB, men det er betalt, selvom det har flere funktioner.

Kopiering af filer er den hurtigste måde at overføre en hel database fra en server til en anden.

2. Kopiering via tekstfiler

For at tælle med backup af data fra produktionsdatabasen er det ikke nødvendigt at trække filerne. Du kan vælge data ved hjælp af en forespørgsel og gemme dem i en tekstfil. For at gøre dette skal du bruge SQL-kommandoen SELECT INTO OUTFILE og dets par LOAD DATA INFILE . Aflæsning sker linje for linje (du kan kun vælge de nødvendige linjer for at gemme, som i en almindelig SELECT). Strukturen af ​​tabellerne er ikke specificeret nogen steder - programmøren skal sørge for dette. Den skal også sørge for at inkludere SELECT INTO OUTFILE-kommandoer i transaktionen, hvis det er nødvendigt for at sikre dataintegritet. I praksis bruges SELECT INTO OUTFILE til delvis backup meget store borde, som ikke kan kopieres på anden måde.

I de fleste tilfælde er mysqldump-værktøjet skabt af Igor Romanenko meget mere praktisk. Mysqldump-værktøjet genererer en fil, der indeholder alle de SQL-kommandoer, der er nødvendige for fuldstændigt at gendanne en database på en anden server. Separate muligheder du kan opnå kompatibilitet af denne fil med næsten enhver DBMS (ikke kun MySQL), derudover er det muligt at downloade data i CSV- og XML-formater. For at gendanne data fra sådanne formater er der et hjælpeprogram kaldet mysqlimport.

Mysqldump-konsolværktøjet. Der er dens tilføjelser og analoger, der giver dig mulighed for at administrere backup via en webgrænseflade, for eksempel det ukrainske værktøj Sypex Dumper (deres repræsentant er på Habré).

Fejl universelle hjælpemidler backup ind tekstfiler- dette er en relativt lav driftshastighed og manglende evne til at lave trinvise sikkerhedskopier.

3. Inkrementelle sikkerhedskopier

Traditionelt anbefales det at opbevare 10 sikkerhedskopier: en for hver dag i ugen, samt sikkerhedskopier fra to uger, en måned og et kvartal siden - dette vil give dig mulighed for at rulle ret dybt tilbage i tilfælde af eventuelle datakorruption.
Sikkerhedskopier bør absolut ikke gemmes på den samme disk som livedatabasen og ikke på den samme server. I tilfælde af brande og andre katastrofer er det bedst at leje et par enheder i et nærliggende datacenter.

Disse krav kan være et problem for store databaser. At uploade en sikkerhedskopi af en 100-gigabyte database over et 100-Mbit netværk vil tage omkring tre timer, hvor kanalen vil være fuldstændig tilstoppet.
Inkrementelle sikkerhedskopier kan delvist løse dette problem, når fuld backup Dette gøres f.eks. kun om søndagen, og på andre dage skrives kun data tilføjet eller ændret i løbet af det seneste døgn. Vanskeligheden er, hvordan man identificerer netop disse "data, der har ændret sig i løbet af dagen."

Her er Percona XtraBackup-systemet, som indeholder en modificeret InnoDB-motor, analyserer MySQL binære logfiler og udtrækker den nødvendige information fra dem, praktisk talt uovertruffen. Den betalte InnoDB Hot Backup nævnt ovenfor har næsten de samme muligheder.

Det generelle problem med enhver backup er, at de altid halter. I tilfælde af en fatal fejl på hovedserveren, vil det kun være muligt at gendanne systemet med en vis "tilbageføring" i tide, hvilket vil meget, meget skuffe dets brugere. Hvis økonomiske strømme i systemet på en eller anden måde blev påvirket, kan sådan et "tilbageslag" bogstaveligt talt koste en pæn krone.

4. Replikation

MySQL-replikeringssystemet er designet til at undgå rollbacks. Ideen om replikering er baseret på det faktum, at ud over "hoved"-serveren ("Master"), kører MySQL-servere ("slaver") konstant, som modtager trinvise sikkerhedskopier fra masteren i realtid. Dermed reduceres tilbagerulningstiden næsten til netværksforsinkelsen. Hvis Master fejler, kan du hurtigt udpege en af ​​slaverne som den "nye Master" og omdirigere klienter til den. Derudover kan slaver behandle anmodninger om at læse data (SELECTs); dette kan bruges til at udføre nogle beregninger eller reducere belastningen på masteren. MySQL understøtter replikering ud af boksen, processen er godt beskrevet af brugeren

Databaseservere er en af ​​nøgleserverne i enhver organisation. Det er dem, der gemmer information og leverer output efter anmodning, og det er ekstremt vigtigt at bevare databasen i enhver situation. Grundlevering inkluderer normalt nødvendige hjælpemidler, men en administrator, der ikke tidligere har stødt på en database, skal bruge lidt tid på at forstå arbejdets særegenheder for at sikre automatisering.

Typer af database backups

Lad os først finde ud af, hvilken slags sikkerhedskopier der er. En databaseserver er ikke en almindelig desktopapplikation, og for at sikre, at alle ACID (Atomic, Consistency, Isolated, Durable) egenskaber er opfyldt, bruges en række teknologier, og derfor har oprettelse og gendannelse af en database fra et arkiv sine egne karakteristika . Der er tre forskellige tilgange til sikkerhedskopiering af data, hver med deres egne fordele og ulemper.

Med en logisk eller SQL backup (pg_dump, mysqldump, SQLCMD) oprettes et øjebliksbillede af indholdet af databasen under hensyntagen til transaktionsintegritet og gemmes som en fil med SQL-kommandoer (du kan vælge hele databasen eller separate tabeller), hvormed du kan genskabe databasen på en anden server. Dette tager tid (især for store databaser) at gemme og gendanne, så meget ofte kan denne operation ikke udføres og udføres under minimal belastning (for eksempel om natten). Ved gendannelse skal administratoren køre flere kommandoer for at forberede alt nødvendigt (opret en tom database, Regnskaber Og så videre).

Fysisk backup (filsystemniveau) - kopiering af filer, som DBMS'et bruger til at gemme data i databasen. Men en simpel kopi ignorerer låse og transaktioner, som sandsynligvis vil blive forkert gemt og ødelagt. Hvis du forsøger at vedhæfte denne fil, vil den være i en inkonsistent tilstand og vil resultere i fejl. For at få en opdateret backup skal databasen stoppes (du kan reducere nedetiden ved at bruge rsync to gange - først på en kørende, så på en stoppet). Ulempen ved denne metode er indlysende - du kan ikke gendanne specifikke data, kun hele databasen. Når du starter en database gendannet fra et filsystemarkiv, skal du kontrollere dens integritet. Her anvendes forskellige hjælpeteknologier. For eksempel i PostgreSQL, WAL (Write Ahead Logs) og speciel funktion(Point in Time Recovery - PITR), som giver dig mulighed for at vende tilbage til en bestemt tilstand af databasen. Med deres hjælp er det tredje scenarie let implementeret, når en sikkerhedskopi på filsystemniveau kombineres med en sikkerhedskopi af WAL-filer. Først gendanner vi filsystemets backupfiler, og derefter ved hjælp af WAL bringes databasen til nuværende tilstand. Dette er en lidt mere kompleks tilgang til administration, men der er ingen problemer med databasens integritet og gendannelse af databaser til et bestemt tidspunkt.

Logisk backup bruges i tilfælde, hvor det er nødvendigt at lave en engangs fuld kopi af databasen eller i daglig brug, at oprette en kopi kræver ikke meget tid eller plads. Når udlæsning af databaser tager meget tid, bør du være opmærksom på fysisk arkivering.

Barmand

Licens: GNU GPL

Understøttet DBMS: PostgreSQL

PostgreSQL understøtter fysiske og logiske sikkerhedskopieringsmuligheder og tilføjer endnu et WAL-lag til dem (se sidebjælke), som kan kaldes kontinuerlig kopiering. Men at administrere flere servere ved hjælp af standardværktøjer er ikke særlig praktisk, selv for en erfaren administrator, og i tilfælde af en fejl, tæller sekunder.

Barman (backup og recovery manager) er en intern udvikling af virksomheden 2ndQuadrant, som leverer tjenester baseret på PostgreSQL. Designet til fysisk PostgreSQL backup (logisk understøtter ikke), WAL arkivering og hurtig bedring efter fiaskoer. Understøtter fjernsikkerhedskopiering og -gendannelse af flere servere, point-in-time-gendannelse (PITR)-funktioner og WAL-administration. SSH bruges til at kopiere og sende kommandoer til en fjernvært; synkronisering og backup ved hjælp af rsync giver dig mulighed for at reducere trafikken. Barman integrerer også med standard hjælpeprogrammer bzip2, gzip, tar og lignende. I princippet kan du bruge et hvilket som helst komprimerings- og arkiveringsprogram, integration vil ikke tage meget tid. Forskellige service- og diagnosefunktioner er blevet implementeret for at overvåge tjenesternes status og regulere båndbredden. Pre/Post-scripts understøttes.

Barman er skrevet i Python, og sikkerhedskopieringspolitikker administreres ved hjælp af den brugervenlige barman.conf INI-fil, som kan findes i /etc eller brugerens hjemmemappe. Inkluderet i leveringen færdiglavet skabelon med detaljerede kommentarer indeni. Virker kun på *nix-systemer. For at installere på RHEL, CentOS og Scientific Linux, skal du tilslutte EPEL - et lager, der indeholder ekstra pakker. Det officielle lager er tilgængeligt for Debian/Ubuntu-brugere:

$ sudo apt-get install barman

Depotet har ikke altid den nyeste version; for at installere det, skal du henvise til kildeteksterne. Der er få afhængigheder, og processen er let at forstå.

Sypex Dumper

Licens: BSD

Understøttet DBMS: MySQL

MySQL kommer med hjælpeprogrammerne mysqldump og mysqlhotcopy, som giver dig mulighed for nemt at oprette et databasedump; de er veldokumenterede, og du kan finde et stort antal færdige eksempler og frontends på internettet. Sidstnævnte giver en nybegynder mulighed for hurtigt at komme i gang. Sypex Dumper er et PHP-script, der giver dig mulighed for nemt at oprette og gendanne en kopi af en MySQL-database. Skabt til at arbejde med store databaser, det virker meget hurtigt, er forståeligt og nemt at bruge. Ved, hvordan man arbejder med MySQL-objekter - visninger, procedurer, funktioner, triggere og hændelser.

Et andet plus, i modsætning til andre værktøjer, der udfører omkodning i UTF-8 ved eksport, udføres eksporten i Dumper i den oprindelige kodning. Den resulterende fil fylder mindre, og selve processen er hurtigere. Ét dump kan indeholde objekter med forskellige kodninger. Desuden er det nemt at importere/eksportere i flere trin, hvilket stopper processen under indlæsning. Når den genoptages, vil proceduren begynde fra det sted, hvor den stoppede. Der er fire muligheder for gendannelse:

• CREATE + INSERT - standardgendannelsestilstand;
• TRUNCATE + INSERT - mindre tid til at oprette tabeller;
• ERSTAT - vi gendanner gamle data i arbejdsdatabasen uden at overskrive nye;
• INSERT IGNORE - vi tilføjer slettede eller nye data til databasen uden at røre ved eksisterende.

Understøtter kopikomprimering (gzip eller bzip2), automatisk sletning af gamle sikkerhedskopier, visning af indholdet af en dumpfil og gendannelse af kun tabelstrukturen. Der er også servicefunktioner til styring af databasen (oprettelse, sletning, kontrol, gendannelse af databasen, optimering, rengøring af tabeller, arbejde med indekser osv.), samt en filhåndtering, der giver dig mulighed for at kopiere filer til serveren.

Administrationen udføres ved hjælp af en webbrowser, grænseflade med bruger AJAX lokaliseret ud af boksen og giver indtryk af at arbejde med en desktop-applikation. Det er også muligt at køre job fra konsollen og på en tidsplan (via cron).

For at Dumper kan fungere, skal du bruge en klassisk L|WAMP-server; installation er standard for alle programmer skrevet i PHP (kopier filer og sæt tilladelser), og det vil ikke være svært, selv for en nybegynder. Projektet giver detaljeret dokumentation og video tutorials, der demonstrerer, hvordan man bruger Sypex Dumper.

Der er to udgaver: Sypex Dumper (gratis) og Pro ($10). Den anden har flere funktioner, alle forskellene er opført på hjemmesiden.

SQL Backup og FTP

Licens:

Understøttet DBMS: FRK SQL Server

MS SQL Server er en af ​​de populære løsninger, og forekommer derfor ret ofte. Et backupjob oprettes ved hjælp af SQL Server Management Studio, Transact-SQL selv og SQL PowerShell-modul-cmdlets (Backup-SqlDatabase). På MS hjemmeside kan du nemt finde stor mængde dokumentation, der hjælper dig med at forstå processen. Selv om dokumentationen er fuldstændig, er den meget specifik, og informationer på internettet modsiger ofte hinanden. En nybegynder skal faktisk først øve sig i at "få hovedet ind", så selv på trods af alt, hvad der er blevet sagt, har tredjepartsudviklere plads til at udvide. Udover gratis version SQL Server Express har ikke indbyggede sikkerhedskopieringsværktøjer. For mere tidligere versioner MS SQL (indtil 2008) kan du finde gratis hjælpeprogrammer, for eksempel SQL Server backup, men i de fleste sådanne projekter er allerede blevet kommercialiseret, selvom de tilbyder al funktionalitet ofte for et symbolsk beløb.

For eksempel følger udviklingen af ​​SQL Backup And FTP og One-Click SQL Restore princippet om "indstil det og glem det". Med en meget enkel og intuitiv grænseflade giver de dig mulighed for at oprette kopier af MS SQL Server (inklusive Express) og Azure-databaser, gemme krypterede og komprimerede filer på FTP og cloud-tjenester (Dropbox, Box, Google Drev, MS SkyDrive eller Amazon S3), kan resultatet ses med det samme. Det er muligt at starte processen enten manuelt eller i henhold til en tidsplan, sende en besked om resultatet af opgaven via e-mail eller køre brugerdefinerede scripts.

Alle sikkerhedskopieringsmuligheder understøttes: fuld, differentiel, transaktionslog, kopiering af en mappe med filer og meget mere. Gamle sikkerhedskopier slettes automatisk. SQL Management Studio bruges til at oprette forbindelse til den virtuelle vært, selvom der kan være nuancer, og dette vil ikke fungere i alle sådanne konfigurationer. Der er fem versioner tilgængelige til download - fra gratis til den sofistikerede Prof Lifetime (på tidspunktet for skrivningen af ​​disse linjer kostede det kun $149). Gratis funktionalitet er ganske tilstrækkeligt til små netværk, hvor en eller to SQL-servere er installeret, er alle grundlæggende funktioner aktive. Antallet af backupdatabaser, muligheden for at sende filer til Google Drive og SkyDrive og filkryptering er begrænset. Selvom grænsefladen ikke er lokaliseret, er den meget enkel og forståelig selv for en nybegynder. Du skal blot oprette forbindelse til SQL-serveren, hvorefter en liste over databaser vil blive vist, du skal vælge dem, du har brug for, konfigurere adgang til eksterne ressourcer og angive tidspunktet for opgavens udførelse. Og alt dette i ét vindue.

Men der er et "men". Selve programmet er ikke beregnet til arkivgendannelse. Til dette tilbydes et separat gratis værktøj, One-Click SQL Restore, som også forstår formatet, der oprettes af BACKUP DATABASE-kommandoen. Administratoren behøver kun at angive arkivet og serveren, som dataene skal gendannes til, og trykke på en knap. Men i mere komplekse scenarier bliver du nødt til at bruge RESTORE.

Funktioner i MS SQL Server backup

Oprettelse af en sikkerhedskopi og gendannelse af et DBMS har sine egne forskelle, der skal tages i betragtning, især når du overfører et arkiv til en anden server. Lad os som et eksempel se på nogle af nuancerne i MS SQL Server. Til arkivering hvornår Transact-SQL hjælp du skal bruge kommandoen BACKUP DATABASE (der er også en differential DIFFERENTIAL) og BACKUP LOG transaktionsloggen.

Hvis sikkerhedskopien er installeret på en anden server, skal du sikre dig, at de samme logiske drev er til stede. Alternativt kan du manuelt indstille de korrekte stier til databasefilerne ved at bruge indstillingen MED MOVE kommandoer GENDAN DATABASE.

En simpel situation - backup og overførsel af databaser til andre versioner af SQL Server. Denne handling er understøttet, men i tilfælde af SQL Server vil den fungere, hvis versionen af ​​serveren, hvor kopien er installeret, er den samme eller nyere end den, den blev oprettet på. Desuden er der en begrænsning: ikke mere end to versioner er nyere. Efter gendannelse vil databasen være i kompatibilitetstilstand med den version, som overgangen blev foretaget med, det vil sige, at nye funktioner ikke vil være tilgængelige. Dette kan nemt rettes ved at ændre COMPATIBILITY_LEVEL. Du kan gøre dette ved at bruge GUI eller SQL.

ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;

Du kan bestemme, hvilken version kopien blev oprettet på, ved at se på arkivfilens overskrift. For at undgå eksperimenter bør du køre det gratis Microsoft Upgrade Advisor-værktøj, når du opgraderer til en ny version af SQL Server.

Iperius

Licens: kommerciel, der er en gratis version

Understøttet DBMS: Oracle 9–11, XE, MySQL, MariaDB, PostgreSQL og MS SQL Server

Når du skal administrere flere typer DBMS, kan du ikke undvære mejetærskere. Udvalget er stort. For eksempel er Iperius let, meget nem at bruge og samtidig kraftfuldt program til fil backup, som har funktionen af ​​hot backup af databaser uden afbrydelse eller blokering. Giver fuld eller trinvis backup. Kan oprette fuld diskbilleder for automatisk at geninstallere hele systemet. Understøtter backup til NAS, USB-enheder, streamer, FTP/FTPS, Google Drive, Dropbox og SkyDrive. Understøtter zip-komprimering uden begrænsning på filstørrelse og AES256-kryptering, lancering af eksterne scripts og programmer. Indeholder en meget funktionel opgaveplanlægger, parallel eller sekventiel udførelse af flere opgaver er mulig, resultatet sendes via e-mail. Talrige filtre, variabler til personalisering af stier og indstillinger understøttes.

FTP-uploadfunktion gør det nemt at opdatere oplysninger på tværs af flere websteder. Åbne filer sikkerhedskopieres ved hjælp af VSS (volume shadow copy) teknologi, som giver dig mulighed for at lave varme sikkerhedskopier af ikke kun DBMS-filer, men også andre applikationer. Til Oracle bruges også RMAN (Recovery Manager) backup- og gendannelsesværktøjet. For at undgå overbelastning af kanalen er det muligt at konfigurere båndbredden. Sikkerhedskopiering og gendannelse administreres ved hjælp af en lokal- og webkonsol. Alle funktioner er synlige, så for at konfigurere en opgave behøver du kun at forstå processen; du behøver ikke engang at se på dokumentationen. Vi følger bare guidens instruktioner. Du kan også notere kontoadministratoren, hvilket er meget praktisk, hvornår store mængder systemer

Grundlæggende funktioner tilbydes gratis, men muligheden for at sikkerhedskopiere en database er kun inkluderet i Avancerede versioner DB og fuld. Installation understøttet fra XP til Windows Server 2012.

Praktisk backup

Licens: en reklame

Understøttet DBMS: Oracle, MySQL, IBM DB2 (7–9.5) og MS SQL Server

En af de mest kraftfulde systemer ledelse relationelle databaser data - IBM DB2, som har unikke skaleringsfunktioner og understøtter mange platforme. Den kommer i flere udgaver, som er bygget på samme base og adskiller sig funktionelt. DB2-databasearkitekturen giver dig mulighed for at administrere næsten alle typer data: dokumenter, XML, mediefiler og så videre. Den gratis DB2 Express-C er særlig populær. Sikkerhedskopiering er meget enkel:

Db2 backup db prøve

Eller et øjebliksbillede ved hjælp af funktionen Advanced Copy Services (ACS):

Db2 backup db prøve brug snapshot

Men vi skal huske, at i tilfælde af snapshots kan vi ikke gendanne (db2 recover db) individuelle tabeller. Der er også muligheder for automatisk backup, og meget mere. Produkterne er dog veldokumenterede Russisksproget internet manualer er sjældne. Det er heller ikke alle brugerdefinerede løsninger, der tilbyder DB2-understøttelse.

For eksempel giver Handy Backup dig mulighed for at sikkerhedskopiere flere typer databaseservere og gemme filer på næsten alle medier ( HDD, CD/DVD, cloud- og netværkslagring, FTP/S, WebDAV og andre). Ledig database backup data via ODBC (kun tabeller). Det er en af ​​de få løsninger, der understøtter DB2 og også bærer "Ready for IBM DB2 Data Server Software"-logoet. Hele proceduren udføres ved hjælp af en almindelig guide, hvor du kun behøver at vælge ønskede vare og lav en opgave. Selve opsætningsprocessen er så enkel, at selv en nybegynder kan finde ud af det. Du kan oprette flere opgaver, der kører efter en tidsplan. Resultatet registreres i en log og sendes på e-mail. Der er ingen grund til at stoppe tjenesten, mens jobbet kører. Arkivet bliver automatisk komprimeret og krypteret, hvilket sikrer dets sikkerhed.

To versioner af Handy Backup understøtter arbejde med DB2 - Office Expert (lokalt) og Server Network (netværk). Virker på computere, der kører Win8/7/Vista/XP eller 2012/2008/2003. Selve implementeringsprocessen er enkel for enhver administrator.

Som du ved, er alle vigtige data på dine websteder, deres indstillinger, artikler, kommentarer og andre oplysninger gemt i databasen. At miste disse oplysninger kan have meget alvorlige konsekvenser for projektet. Derfor er det vigtigt at lave rettidige sikkerhedskopier af databasen mysql data. Disse kopier kan også være meget nyttige, når du flytter et projekt til en anden server.

I denne vejledning vil vi se på, hvordan man sikkerhedskopierer en mysql- eller mariadb-database, samt hvordan man gendanner information i databasen fra en kopi. Derudover viser vi dig, hvordan du opsætter automatisk oprettelse kopier efter et vist tidsrum.

Alt hvad du behøver for en mysql backup er adgang til en server der kører Linux system, hvorpå databaseserveren er installeret, samt databasenavnet og adgangsparametrene.

Du kan bruge mysqldump-værktøjet til at eksportere information fra en database i SQL-format. Her er dens syntaks:

$ mysqldump muligheder databasenavn [tabel_navn] > fil.sql

Som standard vil hjælpeprogrammet udlæse alt til standard output, så vi skal omdirigere disse data til en fil, hvilket vi gør ved at bruge ">" operatoren. Indstillinger angiver godkendelses- og driftsparametre, og navnet på databasen og tabellen angiver de data, der skal eksporteres. Lad os nu kort se på de muligheder, vi vil bruge:

• -EN- kopiere alle tabeller fra alle databaser;
• -jeg- nedskriv yderligere oplysninger i kommentarerne;
• -c- brug kolonnenavne til INSERT-sætningen;
• -en- inkludere alle mulige muligheder i OPRET erklæring BORD;
• -k- deaktiverer primære nøgler under kopieringens varighed;
• -e- brug en flerlinjet version af INSERT-sætningen;
• -f- Fortsæt selv efter en fejl;
• -h- værtsnavn, som databaseserveren er placeret på, som standard localhost;
• -n- skriv ikke instruktioner til oprettelse af en database;
• -t- skriv ikke instruktioner til oprettelse af tabeller;
• -d- nedskriv ikke tabeldata, men kun deres struktur;
• -s- database adgangskode;
• -P- databaseserverport;
• -Q- Sæt alle navne på tabeller, databaser, felter i anførselstegn;
• -X- brug XML-syntaks i stedet for SQL;
• -u- den bruger på hvis vegne du ønsker at oprette forbindelse til databasen.

I de fleste tilfælde er det nok for os at angive et brugernavn, adgangskode og databasenavn. Lad os derefter se på eksempler på at arbejde med værktøjet. For eksempel den enkleste databaseeksportkommando:

mysqldump -u brugernavn -p databasenavn > data-dump.sql

Du skal indtaste databasebrugeradgangskoden, og kommandoen vil ikke udsende noget andet, da vi sendte alle data til en fil, men du kan se sved hjælp af denne kommando:

head -n 5 data-dump.sql

Men hvis der opstår fejl under oprettelse af en kopi, vil de blive vist på skærmen, og du vil straks vide om dem. Mere svær mulighed er at udføre en mysql backup fra en anden vært, hvis du har adgang til den:

mysqldump -h host -P port -u brugernavn -p databasenavn > data-dump.sql

Kopi mysql tabeller kan gøres ved blot at tilføje tabelnavnet til slutningen af ​​linjen:

mysqldump -u brugernavn -p databasenavn tabelnavn > data-dump.sql

For at udføre automatisk sikkerhedskopiering af mysql-databasen skal du muligvis straks indstille en adgangskode; for at gøre dette skal du angive den umiddelbart efter -p-indstillingen, uden et mellemrum:

mysqldump -u brugernavn -ppassword databasenavn > data-dump.sql

Vi kan lave sikkerhedskopier manuelt fra tid til anden, men det er ikke helt bekvemt, da der er andre vigtige ting at gøre. Derfor bruger vi cron-planlæggeren til at automatisere processen. Der er to måder: en enklere og en mere kompleks, men præcis. Lad os sige, at vi skal lave en sikkerhedskopi hver dag, så skal du bare oprette et script i mappen /etc/cron.daily/ med følgende indhold:

sudo vi /etc/cron.daily/mysql-backup

!/bin/bash
/usr/bin/mysqldump -u brugernavn -ppassword databasenavn > /backups/mysql-dump.sql

Mappen /backups/mysql-dump.sql skal erstattes med din egen mappe til sikkerhedskopier. Det eneste, der er tilbage, er at give scriptet tilladelse til at udføre:

chmod ugo+x /etc/cron.daily/mysql-backup

Tilføj følgende linje til den åbnede fil, og gem ændringerne:

30 2 * * * /usr/bin/mysqldump -u brugernavn -ppassword databasenavn > /backups/mysql-dump.sql

Kommandoen udføres hver dag kl. 2:30, dette er praktisk, da der normalt er mindre belastning på serveren om natten. Som du forstår, er det første tal minutterne, det andet er timerne, det tredje er dagen, derefter ugen og måneden. En stjerne betyder, at denne parameter ikke har nogen værdi.

Gendanner fra en sikkerhedskopi

Gendan backup kopiere mysql eller mariadb fra en eksisterende SQL-fil er også meget enkel. Da sql-syntaks blev brugt, kan vi simpelthen udføre alle kommandoerne ved hjælp af standard mysql-klienten.

Først skal du oprette en ny database. For at gøre dette skal du logge ind på mysql server med superbrugerrettigheder:

mysql -u root -s

Opret derefter en ny database, for eksempel med navnet new_database, hvis databasen allerede eksisterer, så behøver du ikke gøre dette:

mysql> CREATE DATABASE new_database;

mysql -u bruger -p database< data-dump.sql

For at eksportere sendte vi standardoutputdataene til en fil, men her sker den omvendte handling, dataene fra filen sendes til programmets standardinput. En vellykket udført kommando vil ikke udsende noget, og for at sikre, at alt lykkedes, skal du blot se på indholdet af databasen.

konklusioner

Nu ved du, hvordan du kopierer en mysql-database, samt hvordan du gendanner den kopierede information. Vi har dækket alle mulige mysqldump-muligheder, så du kan tilpasse værktøjet, som du har brug for. Sikkerhedskopiering af mysql-databasen er et meget vigtigt punkt og kan i visse situationer spare en masse tid, så sørg for at sætte det op på din server!

Der er 5 hovedårsager til datatab:

1. Software fejl— Fremkomsten af ​​forhold, der fører til krak systemer. Fordi sådanne fejl er baseret på defekter i programlogik, kan databasesystemet ikke udføre retablering i sådanne situationer. Derfor skal gendannelsen udføres af programmøren selv efter at have håndteret sådanne undtagelser.
2. Administrator fejl ( menneskelig faktor) — Tilfælde, hvor en bruger med høj autoritet utilsigtet (eller bevidst) kan ødelægge data. Det er nødvendigt at forsøge at skabe en driftsform, der gør en sådan situation usandsynlig, men en sådan mulighed kan ikke helt udelukkes.
3. Computerfejl (systemfejl)— Opstår som følge af fejl i hardware og software. I dette tilfælde indholdet Random Access Memory computer kan gå tabt. Som en beskyttelse kan vi anbefale at bruge en backup-server, spejlrefleksion databaser mv.
4. Diskdrevfejl— Fysisk ødelæggelse harddisk. Det anbefales, at RAID-teknologier bruges til at gemme databasefiler, og at backupfiler gemmes på diskdrev, forskellig fra den enhed, som databasefilerne er placeret på.
5. Katastrofer (brand, oversvømmelse, jordskælv) eller tyveri- Det vil være muligt at omgå denne situation, hvis enheden, der indeholder de nødvendige oplysninger til datagendannelse, opbevares adskilt fra hovedudstyret og ikke går tabt som følge af katastrofer eller tyverier.

Du bør prøve at oprette et backup-system, der giver dig mulighed for at gendanne data i enhver af situationerne beskrevet ovenfor.

2. Typer af backup

Der er 2 sikkerhedskopieringstilstande:

1. Statisk backup- en tilstand, hvor under processen med at oprette en kopi, kun én aktiv session understøttet af systemet er den session, der opretter sikkerhedskopien. Ingen andre brugerprocesser er tilladt, mens kopien kører.
2. Dynamisk backup- en tilstand, hvor databasekopier kan udføres uden at stoppe databaseserveren, slette brugere eller endda lukke filer. Brugere er muligvis ikke klar over, at en sikkerhedskopieringsproces er i gang.

MS SQL Server understøtter begge sikkerhedskopieringstilstande.

3. Databasegendannelsesmodeller

Valget af databasegendannelsesmodel bestemmer mængden af ​​data, der kan gå tabt under databaseødelæggelsen, såvel som brugshastigheden, størrelsen af ​​tranog det tidsrum, der kræves for logsikkerhedskopieringen. MS SQL Server understøtter tre gendannelsesmodeller:

1. Fuld genopretningsmodel- en model, hvor alle operationer registreres i en transaktionslog. Derfor giver denne model fuld beskyttelse mod fejl på eksterne enheder.
   • Fordele:
     1. Det er muligt at gendanne databasen fra den sidste bekræftede transaktion, som blev gemt i logfilen.
     2. Det er muligt at gendanne data til ethvert tidspunkt.
     3. Det er muligt at gendanne data til mærket i protokollen. Mærker i protokollen svarer til en given transaktion og tilføjes kun, hvis denne transaktion bekræftes.
     4. Alle handlinger, der er forbundet med at ændre indekset, logges. I dette tilfælde er genopbygningen af ​​indekset hurtigere, fordi du ikke behøver at genskabe dem.
   • Fejl:
     1. Den tilknyttede transaktionslog kan være meget stor, og diskfilerne, der indeholder loggen, kan vokse i størrelse meget hurtigt. I denne forbindelse er det muligt at udfylde en transaktionsprotokol.
     2. Transaktionsprotokollen skal beskyttes mod fejl på eksterne enheder. Af denne grund anbefales det kraftigt at bruge RAID-teknologi til at beskytte transaktionsloggen.
     3. Der kræves væsentligt længere backup-tider.
   • Konklusion:
     Denne gendannelsesmodel anbefales til produktionsdatabaser, hvis databaseserverhardwaren tillader det.
2. Bulk-logget gendannelsesmodel— Samme som den fulde genvindingsmodel, bortset fra at masse- eller bulkoperationer ikke logges. Og sikkerhedskopier af transaktionsloggen indeholder i dette tilfælde resultatet af en sådan operation.
   • Fordele:
     1. Som med den fulde gendannelsesmodel er det muligt at gendanne databasen fra den sidste forpligtede transaktion, der blev gemt i logfilen.
     2. Det er muligt at gendanne data på et hvilket som helst tidspunkt, hvis der ikke blev udført store operationer.
     3. Det er muligt at gendanne data til mærket i protokollen, hvis der ikke var store operationer.
     4. Masseoperationer er meget hurtigere end under den fulde gendannelsesmodel, fordi de ikke logges.
     5. En protokol backup kræver meget mindre hukommelse end en fuld gendannelse.
   • Fejl:
     1. Det samme som med fuld recovery-modellen.
     2. Handlinger, der ændrer indekset, logges ikke. Ved gendannelse skal indekserne oprettes igen.
     3. Gendannelse fra en protokolsikkerhedskopi tager længere tid end med den fulde gendannelsesmodel.
     4. Der er ingen måde at gendanne data til et tidspunkt eller til et punkt i protokollen i tilfælde af store operationer.
   • Konklusion:
     Den bulk-loggede gendannelsesmodel bruges til produktionsdatabaser, hvor storskala eller højvolumen bulkoperationer forekommer periodisk.
3. Enkel gendannelsesmodel - I den simple gendannelsesmodel afkortes transaktionsloggen, hvis der opstår et gendannelsespunkt. Men det betyder ikke, at der overhovedet ikke er nogen logning; indholdet af loggen bruges under checkpointing, hvor alle protokoltransaktioner bliver begået eller rullet tilbage.
   • Fordele:
     1. Produktiviteten af ​​alle volumetriske operationer er meget høj.
     2. Lave krav til protokolhukommelse.
   • Fejl:
     1. Data kan kun gendannes til tidspunktet for sidste sikkerhedskopiering, hvilket betyder, at gendannelse til et bestemt tidspunkt eller til et punkt i protokollen ikke er tilladt. Alle ændringer fra den sidste backup skal gendannes manuelt.
   • Konklusion:
     Anbefales at bruge simpel model gendannelse til produktionsdatabaser, kun i tilfælde, hvor databaseserveren ikke har tilstrækkelig hukommelse, eller når databaseserverhardwaren er lavere end anbefalet.

4. Backup metoder

MS SQL Server tilbyder 4 forskellige sikkerhedskopieringsmetoder:

1. Fuld database kopi(Fuld) — En fuld sikkerhedskopi opretter en sikkerhedskopi af hele databasen, den inkluderer skemaet for alle tabeller, den tilsvarende filstrukturer, og indeholder også alle data fra denne database på det tidspunkt færdiggørelse Reserve eksemplar. Dette gøres, fordi en fuld kopi fanger databasens tilstand ved starten af ​​kopien. Og så, hvis kopieringen udføres dynamisk, registrerer systemet alle handlinger, der finder sted, mens kopien oprettes.
   • Fordele:
     Hurtig hastighed databasegendannelse.
   • Fejl:
     En fuld backup tager længere tid og kræver mere lagerplads end andre backupmetoder.
   • Konklusion:
     For små databaser, der kan sikkerhedskopieres hurtigt, er det bedst at bruge en fuld backup. Men for store databaser er det udover fuld backup også nødvendigt at lave differentierede (differentierede) kopier af databaserne.
     
2. Differentiel (differentiel) backup(Differential) - I dette tilfælde oprettes der kun en kopi af de dele af databaserne, der er ændret siden den sidste komplette kopi af databaserne. Denne fulde backup kaldes basis for en differentiel kopi. Som med en fuld sikkerhedskopi, bliver enhver aktivitet, der opstår, mens sikkerhedskopien oprettes, også sikkerhedskopieret.
   • Fordele:
     Denne type sikkerhedskopiering minimerer den tid, der kræves til kopiering, fordi mængden af ​​kopierede data er væsentligt mindre end med en fuld sikkerhedskopiering.
   • Fejl:
     For at gendanne skal du først downloade en fuld kopi af databaserne og derefter en differentiel, hvilket tager længere tid. Og derfor nytter det ikke noget at bruge differentiel kopiering uden fuld kopiering.
   • Konklusion:
     Anvendes på store databaser i forbindelse med fuld backup.
3. Sikkerhedskopiering af transaktionslog(Transaktionslog) - Denne type kopiering bruges med en fuld gendannelsesmodel (eller med delvis logning) af databaser og tager kun hensyn til de ændringer, der er registreret i transaktionsloggen. Derfor er denne form for backup ikke afhængig af fysiske databasesider, men kun på logiske operationer.
   • Fordele:
     1. For det meste hurtig hastighed oprettelse af en kopi.
     2. I modsætning til differentierede sikkerhedskopier, hvor det kun er muligt at gendanne databasen til tidspunktet for den sidste kopi, giver det dig mulighed for at gendanne databasen til et bestemt tidspunkt.
     3. Korrekt "lukning" af transaktionsprotokollen, før du starter en ny del af handlinger med denne protokol. En af de mest almindelige fejl systemet opstår, når transaktionsloggen bliver fuld. Hvis hukommelsen brugt til transaktionsloggen bliver 100 % fuld, skal systemet stoppe alle udførende transaktioner, indtil hukommelsen er frigivet. Dette problem kan kun elimineres ved hyppigt at sikkerhedskopiere transaktionsprotokollen: hver gang en del af den eksisterende protokol "lukkes" og gemmes på en anden ekstern enhed. Denne del af protokollen bliver genbrugelig, og systemet gendanner derfor diskplads.
   • Fejl:
     Mere lang proces gendannelse end med en differentieret backup, som kræver en fuld kopi af databasen og sidst forskel kopi, i I dette tilfælde du skal bruge en komplet kopi og Alle eksisterende kopier af transaktionslogfiler.
   • Konklusion:
     Det anbefales at bruge det på produktionsdatabaser i forbindelse med en fuld backup.
     
4. Sikkerhedskopiering af filer eller filgrupper — Denne metode giver dig mulighed for at kopiere angivne filer databaser i stedet for at kopiere hele databasen. Individuelle filer kan gendannes fra en kopi, så du kan genoprette fra en fejl, der kun påvirker en lille undergruppe af databasefiler.
   • Konklusion:
     Kopiering af databasefiler anbefales kun, når databasen er meget stor, og der ikke er tid nok til at kopiere databasen fuldstændigt.

5. Hvilke databaser og hvor ofte skal jeg kopiere dem?

1. Database mestre er den vigtigste database i et system, fordi den indeholder information om alle databaserne i det system. Derfor sikkerhedskopieres databasen mestre skal ske med jævne mellemrum. Derudover anbefales det at oprette en kopi, hver gang der udføres en handling, der resulterer i ændring af databasen mestre. Her er nogle af dem:
   • Udførelse af erklæringer og lagrede procedurer;
   • Oprettelse, ændring og sletning af en database;
   • Ændringer i transaktionsprotokollen.
2. Du bør sikkerhedskopiere alt produktion databaser med jævne mellemrum. Derudover er det nødvendigt at lave en sikkerhedskopi efter følgende ændringer er foretaget i databaserne:
   • Efter oprettelse af databasen;
   • Efter oprettelse af indekserne;
   Microsoft SQL Server 2008 R2

Database:

• Samlet databasestørrelse: ~ 95 GB
• Database størrelse mestre: ~5 MB
• Database størrelse D.B.1 : ~ 23 GB
• Databasegendannelsesmodel D.B.1 : Fuld
• Vækst i databasen D.B.1 pr. dag: ~ 200 MB

Database backups D.B.1 :

• Tid til at oprette en fuld backup: ~ 5 min.
• Tid til at oprette en kopi af transaktionsprotokollen: ~ 4 sek.
• Fuld sikkerhedskopieringsstørrelse (komprimeret): ~1,6 GB
• Transaktionslogkopistørrelse: ~ 20 MB

Nødvendig diskplads til backup-plan D.B.1 :

• Fuld backup-lagerplads (1 måned): ~50 GB
• Opbevaring af transaktionsprotokolkopier (1 måned): ~ 10 GB
• Opbevaring fulde kopier fra den 1. i hver måned (1 år): ~ 20 GB
• Samlet størrelse diskplads: ~ 80 GB
• Samlet diskplads i procent af databasestørrelsen: ~ 350 %

Databasegendannelsestid DB1:

• Fuld backup-gendannelsestid: ~5 min.
• Tid til at gendanne en kopi af transaktionsprotokollen: ~ 5 sek.

hjalp det dig denne artikel?

Det forrige foredrag diskuterede emnet sikkerhed – beskyttelse af data mod uautoriseret adgang. Dette foredrag taler om at beskytte data mod uventet tab. Forebyggelse af datatab er en af ​​de mest vigtige spørgsmål som du kan støde på, når du administrerer databasesystemer. Datatab kan opstå som følge af mange forskellige problemer.

Hardware fejl

• Forkert brug af UPDATE- og DELETE-udsagn

  Software fejl

  Nødsituationer, såsom brand eller oversvømmelse

For at undgå tab af data kan du implementere en gendannelsesstrategi for databasen. Genopretningsstrategien skal planlægges, implementeres og afprøves under hensyntagen mulige funktionsfejl, som kan støde på under driften af ​​systemet, og det nødvendige niveau af databeskyttelse. I data marts, det vil sige tilfælde, hvor data kan gendannes fra andre systemer, er det sandsynligvis ikke nødvendigt at tage backup af hver enkelt transaktion. Det kan være tilstrækkeligt at udføre fuld sikkerhedskopiering af dine data med jævne mellemrum. Omvendt, for en database, der gemmer transaktioner i onlinebutik, kan det være nødvendigt at vedligeholde sikkerhedskopier af hver enkelt transaktion. SQL Server DBMS giver et komplet udvalg af funktioner til at implementere præcis den type backup, du har brug for. Dette foredrag diskuterer de mest udbredte strategier til beskyttelse af data i Microsoft SQL Server.

Fuld database backup

Den mest almindelige backup-strategi er at sikkerhedskopiere hele databasen med forudbestemte intervaller (for eksempel hver nat). Med denne katastrofegendannelsesstrategi kan du gendanne din database til den tilstand, den var i, da du sidst tog en sikkerhedskopi. Denne strategi implementeres ved at udføre fuld database backup, som diskuteret nedenfor.

En komplet database backup indeholder alle de databasedata og metainformationer, der er nødvendige for at gendanne databasen fulde data, herunder fuldtekstkataloger. Når du gendanner en database fra en fuld sikkerhedskopi, gendannes alle filer i databasen, og dataene hentes i en konsistent tilstand på det tidspunkt, hvor sikkerhedskopieringen blev udført. Mens sikkerhedskopieringen kører, er databasen i produktionstilstand, og brugeren kan udføre transaktioner og ændre data på den sædvanlige måde. Udtrykket "konsistent tilstand" betyder, at alle transaktioner, der blev foretaget, mens databasesikkerhedskopieringen kørte, anvendes, og alle transaktioner, der ikke blev forpligtet, rulles tilbage. For situationer, der kan føre til tab af datakonsistens pga udførelse af transaktionerændrer data under backup-processen, har SQL Server en speciel proces, der hjælper med at sikre datakonsistens. Denne proces skriver både datasiderne og transaktionsloggen til backup-enheden.

Råd. Fuldtekstkataloger blev indtastet i databaser for at blive tilføjet til SQL Server funktioner fuldtekstindeksering. Fuldtekstindeksering giver dig mulighed for at søge i databasen hurtigere og med større nøjagtighed. For mere information om fuldtekstindeksering, se SQL Server Books Online, Full-Text Indexes.

Sikkerhedskopieringshastigheden bestemmes af hastigheden af ​​de anvendte input/outputenheder (de input/outputenheder, der bruges til at indsamle og gemme information). At opnå bedste præstation SQL Server læser filer sekventielt. Hvis dine I/O-enheder er i stand til samtidigt at behandle backup I/O-data og I/O-data, der kommer fra normal systembrug, vil oprettelse af en backup have en ubetydelig indvirkning på systemets ydeevne. Det er dog bedre at udføre en fuld database backup, når der ikke er nogen spidsbelastninger.

I det næste afsnit vil vi se på mulighederne for at implementere denne backupstrategi.

Enkel gendannelsesmodel

Du bør på forhånd give SQL Server besked om, hvilken type sikkerhedskopiering du har tænkt dig at bruge, så du skal konfigurere databasen til at matche den sikkerhedskopieringstype, du vælger. Denne konfiguration udføres ved at vælge indstillingen Databasegendannelsesmodel. Staner afledt af gendannelsesmodellen for databasemodellen, der blev defineret, da databasen blev oprettet. For at implementere en sikkerhedskopieringsstrategi, der kun inkluderer fuld sikkerhedskopiering, skal du vælge den simple gendannelsesmodel (SIMPLE).

Valg af SIMPLE-gendannelsesmodellen

Fra menuen Start skal du vælge Alle programmer. Microsoft SQL Server 2005, SQL Server Management Studio (Alle programmer, Microsoft SQL Server 2005, SQL Server Management Studio).

I dialogboksen Opret forbindelse til server skal du klikke på knappen Opret forbindelse.

Klik på knappen Ny forespørgsel på standardværktøjslinjen for at åbne vinduet Ny forespørgsel.

For at indstille gendannelsesmodellen kan du bruge ALTER-erklæring DATABASE. Indtast teksten til den følgende instruktion, og klik på knappen Udfør.

ALTER DATABASE AdventureWorks

SÆT GENDANNELSE ENKELT;

Yderligere Information.Dette foredrag fokuserer primært på oprettelse af sikkerhedskopier og gendannelse ved hjælp af SQL-sætninger. Foredrag 6-7 vil dække, hvordan man udfører mange af de samme procedurer, ikke gennem T-SQL-sætninger, men gennem brugergrænsefladen i SQL Server Management Studio.

Kontrollerer indstillingerne for disaster recovery-modellen

For at se den gendannelsesmodel, der er angivet for en database, kan du bruge funktionen DATABASEPROPERTYEX, som henter indstillingerne for den aktuelle datobase eller egenskaber for den angivne database. Følg instruktionerne nedenfor for at udtrække oplysninger om AdventureWorks-databasegendannelsesmodellen.

SELECT DATABASEPROPERTYEX("AdventureWorks","Recovery")

Sørg for, at forespørgselsresultaterne inkluderer SIMPLE-gendannelsesmodellen.

Luk vinduet SQL Server Management Studio.

Backup enheder

Før du begynder at udføre sikkerhedskopiering, skal du bestemme, hvor dine sikkerhedskopier vil blive gemt. Det sted, hvor sikkerhedskopier er gemt, kaldes en backup-enhed. Hver backup-enhed kan gemme flere sikkerhedskopier af forskellige typer. Der er to forskellige typer backup-enheder:

Båndenheder.Kan bruges til at gemme sikkerhedskopier på bånd. Båndenheder skal installeres lokalt. En sikkerhedskopi kan strække sig over flere bånd, og et enkelt bånd kan indeholde både SQL Server- og Windows-sikkerhedskopier.

Diskenheder. Filer på lokale eller fjerndisk eller diskdrev. Disse filer tilgås ved at angive stien til den fil, hvor sikkerhedskopien er gemt. Brug en UNC-sti for at få adgang til fjernlagre.

Bemærk. Denne bog dækker kun sikkerhedskopiering til diskenheder. Backup SQL filer Server på båndenheder bruges ikke særlig ofte i disse dage. Hvis SQL Server-sikkerhedskopier er gemt på bånd, oprettes de normalt ved hjælp af programmer tredjeparts udviklere det tilbud ekstra funktioner, for eksempel ved hjælp af fjernlagring af bånd. Alternativt kan en båndenhed bruges til at yde yderligere forsikring mod data, der allerede er sikkerhedskopieret på en diskenhed.

Backup-enheder identificeres ved deres enhedsnavn. Enhedsnavnet kan være et logisk eller fysisk enhedsnavn. Det fysiske diskenhedsnavn er stien til backupfilen, f.eks. "\\BACKUPSERVER\Backups\adv\AdventureWorks.bak". Denne sti kan inkluderes direkte i backup-erklæringen. Det logiske enhedsnavn er et navn, der peger på navnet på den fysiske backup-enhed og er gemt i SQL Server. Når et logisk enhedsnavn bruges i en sikkerhedskopisætning, leder SQL Server efter den tilsvarende fysiske enhed i systemkataloget og udfører sikkerhedskopieringen og gemmer sikkerhedskopien i den angivne mappe.

At tilføje til systemmappe logisk enhed, kan du bruge sp_addumpdevice lagrede procedure. Følgende eksempel definerer en logisk enhed ved navn Adv_FullDb_Dev.

EXEC sp add-enhed "disk", "AdvFullDbDev", "T:\BACKUPS\AdvFullDbDev.bak";

Råd. Sørg for at ændre filstien, så den passer til din computer. T:/, og skift derefter denne del af filstien i instruktionerne, så den matcher drevbogstavet på din computer. Sørg også for, at alle mapper, der er angivet i denne sti, findes på din computer.

Logiske og fysiske enhedsnavne kan udskiftes; begge navne kan bruges til databasesikkerhedskopiering og -gendannelse. Selvfølgelig er det generelt bedst at bruge en af ​​de to navngivningskonventioner til enhver tid for at holde din kode enkel. Du bør på forhånd vælge den aftale, som du bedst kan lide.

Du skal aldrig bakke op til diskenhed, som ligger på den samme fysiske lagerenhed som selve databasen. Selvom disklagring er fejltolerant på grund af RAID, er der altid mulighed for controllerfejl og datakorruption på diskene. Derudover bør du overveje at gemme backup-enhedens sikkerhedskopieringsfiler på bånd og gemme disse bånd et fjerntliggende sted.

Råd. Forkortelsen RAID kommer fra udtrykket "redundant array of uafhængige diske". Disse arrays er disksystemer med flere drev, der bruges til at øge lagertilgængeligheden og kapaciteten.

Udførelse af en komplet database backup

Når du har indstillet backup-modellen til SIMPLE og besluttet, hvilken backup-enhed du vil gemme dine backups på, kan du begynde at udføre dine backups. En fuld database backup udføres ved hjælp af en ret simpel BACKUP DATABASE statement. I sin enkleste form behøver du kun at fortælle systemet, hvilken database der skal sikkerhedskopieres og på hvilken enhed den skal gemme. For at sikkerhedskopiere AdventureWorks-databasen til en forudvalgt logisk enhed skal du bruge følgende T-SQL-sætning:

TO Adv_FullDb_Dev;

Hvis du ønsker at udføre en komplet databasesikkerhedskopiering til en fysisk enhed, skal du angive enhedstypen og placeringen af ​​sikkerhedskopieringen i BACKUP DATABASE-sætningen. Brug følgende instruktioner for at oprette en sikkerhedskopi af databasen i mappen t:\adv.bak:

BACKUP DATABASE AdventureWorks

TO DISK="t:\adv.bak";

Som nævnt kan enhver backup-enhed gemme mere end én backup. Argumentet til BACKUP DATABASE-sætningen kan angive, om SQL Server skal overskrive den eksisterende sikkerhedskopi på denne enhed eller tilføje den til eksisterende sikkerhedskopier. Til dette formål bruges de søgeord INIT eller NOINIT. Hvis du angiver INIT, formateres sikkerhedskopieringsenheden, før en sikkerhedskopiering startes, og alle sikkerhedskopier, der er på den pågældende enhed, slettes. NOINIT, som er standarden, medmindre andet er angivet, tillader SQL Server at tilføje en sikkerhedskopi til en eksisterende sikkerhedskopieringsenhed og bevare alle eksisterende sikkerhedskopier på den. Disse muligheder indstilles ved hjælp af WITH-blokken i slutningen af ​​BACKUP DATABASE-sætningen.

Hvis du vil oprette den samme sikkerhedskopi som det foregående eksempel, men bed SQL Server om at slette enheden først, skal du bruge følgende sætning:

BACKUP DATABASE AdventureWorks

TO DISK="t:\adv.bak"

Som du kan se, er det ikke svært at udføre en fuld database backup. I næste afsnit vil du se, at en fuld backup er den grundlæggende backup-type, som alle andre backup-typer er bygget på. Andre typer sikkerhedskopier afhænger af at have en fuld backup, fordi de kræver den gendannede database som udgangspunkt. Disse typer sikkerhedskopier, herunder differentielle sikkerhedskopier, bevarer ændringer, der blev foretaget i databasen, efter at en fuld sikkerhedskopi blev oprettet. Således kan vi se, at fuld backup er vigtig ikke kun i en gendannelsesstrategi, der kun udfører en fuld backup, men også i andre backupstrategier, som diskuteres nedenfor.

Differentiel backup

Den største fordel ved en fuld database backup er, at en fuld backup indeholder alle de data, der er nødvendige for at gendanne hele databasen. Men denne fordel kan også være en ulempe. Forestil dig en database, der sikkerhedskopieres hver nat. Hvis du skal gendanne databasen, skal du alligevel bruge sidste nats backup, og som følge heraf mister du en hel dags arbejde. En måde at reducere den potentielle mængde tid, der kan gå glip af sikkerhedskopier, er at udføre fuld database backup oftere. Men dette er i sig selv problematisk. Da alle data- og transaktionslogfragmenter skrives til sikkerhedskopieringsenheden, kan sikkerhedskopieringen tage lang tid at fuldføre. Derudover kræver lagring af alle disse sikkerhedskopier meget diskplads h°, og en fuld backup kan reducere databasens ydeevne på grund af den store mængde I/O, der kræves. Ville det ikke være bedre at sikkerhedskopiere én gang om natten og derefter kun sikkerhedskopiere de data, der blev ændret i løbet af dagen? Sådan funktionalitet giver en differentiel backup-type.

En differentiel sikkerhedskopiering gemmer kun dataændringer, der er sket efter den fulde sikkerhedskopi blev oprettet. Hvis de samme data har ændret sig flere gange, siden den fulde sikkerhedskopi blev oprettet, så bevarer en differentiel sikkerhedskopi det meste nyeste versionændrede data. For at gendanne data fra en differentiel backup skal du først gendanne de fulde backupdata og derefter kun anvende den seneste differentielle backup, som vist i ris. 4.1.

Ris. 4.1. Backup-strategi ved hjælp af differentiel backup

Udførelse af en differentiel backup

At udføre en differentiel backup er ikke meget anderledes end at udføre en fuld backup. Den eneste forskel er, at WITH-blokken erklærer instruktioner til oprettelse af en differentiel backup. Syntaksen for BACKUP DATABASE-sætningen til at sikkerhedskopiere Adventure Works-databasen til fysisk enhed med overskrivning af andre eksisterende sikkerhedskopier på denne enhed vil være sådan:

BACKUP DATABASE AdventureWorks

TO DISK="t:\adv_diff.bak"

MED INIT, DIFFERENTIAL;

Hvis du vil bruge en logisk enhed, skal du først oprette den, ligesom med en fuld backup.

EXEC sp_addumpdevice "disk", "Adv_Diff_Dev",

"T:\BACKUPS\AdvDiffDev.bak";

BACKUP DATABASE AdventureWorks

TIL Adv_Diff_Dev

MED INIT, DIFFERENTIAL;

Vigtig. For at gendanne data fra en differentiel backup skal du altid have den seneste fulde backup. Pas på ikke at overskrive eller slette en komplet databasesikkerhedskopi, mens den er nødvendig for at gendanne data fra differentielle sikkerhedskopier.

Sikkerhedskopiering af transaktionslog

Ved at kombinere hele og differentielle kopier af en database kan du oprette et øjebliksbillede af dine data og gendanne dem. Men i nogle situationer er det også ønskeligt at have sikkerhedskopier af alle hændelser, der opstod i databasen, ned til registreringer af hver sætning, der udføres. På denne måde ville det være muligt at gendanne databasen til enhver påkrævet tilstand. Sikkerhedskopiering af transaktionslog giver netop en sådan mulighed. Som navnet antyder, opretter metoden til backup af transaktionslog sikkerhedskopier af alle transaktionslogposter, der er opstået i databasen. De vigtigste fordele ved backup af transaktionslog er som følger:

Sikkerhedskopiering af transaktionslog giver dig mulighed for at gendanne data til et bestemt tidspunkt.

Fordi sikkerhedskopiering af transaktionslog opretter sikkerhedskopier af logposter, kan du sikkerhedskopiere fra transaktionsloggen, selvom dataene er beskadiget. Ved at bruge en sådan backup kan du gendanne databasen tilbage til den sidste transaktion, der fandt sted, før problemerne begyndte. På denne måde, hvis der opstår en fejl, vil ingen af ​​de forpligtede transaktioner gå tabt.

Som med differentielle sikkerhedskopier kræver gendannelse af en database fra sikkerhedskopier af transaktionslog i en gendannelsesstrategi en underliggende fuld databasesikkerhedskopiering. En backup-strategi ved hjælp af transaktionslog-backups er vist i ris. 4.2. Fuld databasesikkerhedskopiering udføres uden for myldretiden, og trudføres på bestemte tidspunkter i løbet af dagen. Sikkerhedskopier af transaktionslog indeholder alle transaktioner, der er fundet sted, siden den sidste backup af transaktionslog blev oprettet. For at gendanne en database ved hjælp af sikkerhedskopier af transaktionslog skal du derfor have en fuld databasesikkerhedskopiering og alle sikkerhedskopier af transaktionslog, siden den fulde backup blev oprettet. Som du kan se, er det vigtigt, at alle sikkerhedskopier er tilgængelige. Hvis en komplet database-backup eller en af ​​transaktionslog-backuperne går tabt, vil det ikke være muligt at gendanne den ønskede mængde data.

Ris. 4.2. Backup-strategi ved hjælp af transaktionslog-backups

Kombination af differential- og transaktionslog-backups

En anden mulig strategi er en kombination af komplet og forskellige metoder backup med transaktionslog backup. Denne strategi bruges, når det ville være for tidskrævende at gendanne data fra sikkerhedskopier af transaktionslog. Fordi gendannelse af data fra en transaktionslog backup betyder, at alle transaktioner skal udføres igen, kan gendannelse af alle data, især i store databaser, tage meget lang tid. Differentielle sikkerhedskopier anvender kun dataændringer, der kan gennemføres hurtigere sammenlignet med at køre alle transaktioner igen.

At gendanne databasen ved brug af en kombineret strategi som vist i ris. 4.3, skal du først gendanne dataene fra den sidste fulde backup, derefter den sidste differentielle backup og til sidst dataene fra alle efterfølgende transaktionslog backups.

Ris. 4.3. Kombineret backup strategi

For f.eks. at gendanne data til en T3-transaktionslog-backup, skal du gendanne F1-fuld backup, D1-differentiel backup og T3-transaktionslog-backup.

Tidsintervallet mellem sikkerhedskopiering af transaktionslog afhænger af:

Antallet og størrelsen af ​​transaktioner udført i databasen. Med denne backupstrategi skal SQL Server beholde alle transaktioner, indtil transaktionsloggen er sikkerhedskopieret. Derfor skal transaktionslogfilen indeholde alle transaktioner, der fandt sted i tidsrummet mellem to på hinanden følgende sikkerhedskopiering af transaktionslog. Hvis loggen fyldes for hurtigt, bør du reducere tidsintervallet mellem sikkerhedskopiering af transaktionslog eller øge størrelsen på transaktionslogfilen.

Acceptabel mængde datatab. Som nævnt ovenfor er det muligt at gendanne data tilbage til den sidste transaktion, hvis datafiler går tabt. Men hvis transaktionsloggen bliver ødelagt eller tabt, kan du kun gendanne dataene til punktet for den sidste backup af transaktionsloggen. Reduktion af tidsrummet mellem sikkerhedskopiering af transaktionslog vil reducere mængden af ​​tabte data i denne situation.