{"id":92367,"date":"2020-08-26T07:42:09","date_gmt":"2020-08-26T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh"},"modified":"2020-08-26T07:42:09","modified_gmt":"2020-08-26T05:42:09","slug":"putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","title":{"rendered":"Guide til backup af databaser","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<blockquote><p>\u2013 \u00c5h, intet tilflugtssted kan modst\u00e5 et meteornedslag. Men ligesom alle andre har du en backup, s\u00e5 du beh\u00f8ver ikke bekymre dig.<\/p>\n<p><i>Stanislav Lem, \"Stjernedagb\u00f8gerne af Ijon Tichy\"<\/i><\/p><\/blockquote>\n<p>\nBackup refererer til opbevaring af en kopi af data et eller andet sted uden for hovedlagringsstedet.<\/p>\n<p><img decoding=\"async\" alt=\"Guide til backup af databaser\" src=\"\/wp-content\/uploads\/2020\/08\/c1dba0d8999cab69315560dfc57546e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHovedform\u00e5let med backup er at genoprette data efter tab. Derfor h\u00f8rer man ofte, at med en replika af databasen kan data altid genoprettes, og backup er un\u00f8dvendig. I virkeligheden l\u00f8ser backup mindst tre opgaver, som ikke kan l\u00f8ses med en replika, og man kan ikke engang initialisere replikaen uden en backup.<\/p>\n<p>For det f\u00f8rste g\u00f8r en backup det muligt at genoprette data efter en logisk fejl. For eksempel, hvis revisoren sletter en gruppe posteringer, eller databasen administratoren \u00f8del\u00e6gger et tabelrum. Begge operationer er fuldst\u00e6ndig legitime set fra databasen perspektiv, og replikationsprocessen vil gengive dem i replika-databasen.<\/p>\n<p>For det andet er moderne DBMS'er meget p\u00e5lidelige softwarepakker, men af og til sker der stadig skader p\u00e5 databasen interne strukturer, hvorefter adgangen til data g\u00e5r tabt. Dette er s\u00e6rligt \u00e6rgerligt, da s\u00e5danne overtr\u00e6delser ofte sker under h\u00f8j belastning eller ved installation af en eller anden opdatering. Men b\u00e5de h\u00f8j belastning og regelm\u00e6ssige opdateringer tyder p\u00e5, at databasen bestemt ikke er testm\u00e6ssig, og de data, der opbevares i den, er v\u00e6rdifulde.<\/p>\n<p>Endelig er den tredje opgave, hvis l\u00f8sning kr\u00e6ver en backup, kloning af databasen, for eksempel til testform\u00e5l.<\/p>\n<p>Backup af databaser er p\u00e5 en eller anden m\u00e5de baseret p\u00e5 et af to principper:<\/p>\n<ul>\n<li>Udtagning af data efterfulgt af gemt i et vilk\u00e5rligt format;<\/li>\n<li>Snapshot af databasefiler og opbevaring af logs.<\/li>\n<\/ul>\n<p>\nLad os se n\u00e6rmere p\u00e5 disse principper og de v\u00e6rkt\u00f8jer, der implementerer dem.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Dataudtr\u00e6k<\/h3>\n<p>\nBlandt de v\u00e6rkt\u00f8jer, der f\u00f8lger med enhver DBMS, er der altid v\u00e6rkt\u00f8jer til at eksportere og importere data. Data gemmes enten i tekstformat eller i et bin\u00e6rt format, der er specifikt for den p\u00e5g\u00e6ldende DBMS. Tabellen nedenfor viser s\u00e5danne v\u00e6rkt\u00f8jer:<\/p>\n<p>Bin\u00e6rt format<br \/>\nTekstformat<\/p>\n<p>Oracle<br \/>\nDataPump Export\/DataPump Import<br \/>\nEksport\/Import<br \/>\nSQL*Plus\/SQL*Loader<\/p>\n<p>PostgreSQL<br \/>\npg_dump, pg_dumpall\/pg_restore<br \/>\npg_dump, pg_dumpall\/psql<\/p>\n<p>Microsoft SQL Server<br \/>\nbcp<br \/>\nbcp<\/p>\n<p>DB2<br \/>\nunload\/load<br \/>\nunload\/load<\/p>\n<p>MySQL<\/p>\n<p>mysqldump, mysqlpump\/mysql, mysqlimport<\/p>\n<p>MongoDB<br \/>\nmongodump\/mongorestore<br \/>\nmongoexport\/mongoimport<\/p>\n<p>Cassandra<br \/>\nnodetool snapshot\/sstableloader<br \/>\ncqlsh<\/p>\n<p>\nDen tekstbaserede format er godt, fordi det kan redigeres eller endda oprettes af eksterne programmer, mens det bin\u00e6re format p\u00e5 sin side er godt, fordi det muligg\u00f8r hurtigere eksport og import af data ved at spare ressourcer p\u00e5 formatkonvertering.<\/p>\n<p>P\u00e5 trods af enkelheden og \u00e5benlyse id\u00e9en om datatransport, anvendes denne metode sj\u00e6ldent til at sikkerhedskopiere belastede industrielle databaser. Her er grundene til, at eksport ikke er egnet til fuldgyldig sikkerhedskopiering:<\/p>\n<ul>\n<li>eksportprocessen skaber en betydelig belastning p\u00e5 kilde-systemet;<\/li>\n<li>eksporten tager lang tid \u2013 ved afslutningen af eksporten vil den allerede v\u00e6re for\u00e6ldet;<\/li>\n<li>det er praktisk talt umuligt at opn\u00e5 en sammenh\u00e6ngende eksport af hele databasen under h\u00f8j belastning, da DBMS er tvunget til at gemme et snapshot af sin tilstand p\u00e5 det tidspunkt, hvor eksporten starter. Jo flere transaktioner der er foretaget siden eksports start, desto st\u00f8rre bliver st\u00f8rrelsen af snapshot (for\u00e6ldede data i PostgreSQL, undo-omr\u00e5de i Oracle, tempdb i Microsoft SQL Server osv.);<\/li>\n<li>eksporten bevarer den logiske struktur af data, men ikke den fysiske struktur \u2013 parametre for fysisk lagring af tabeller, indekser osv.<\/li>\n<\/ul>\n<p>\nAlligevel har eksporten sine fordele:<\/p>\n<ul>\n<li>h\u00f8j selektivitet: man kan eksportere specifikke tabeller, specifikke felter og endda specifikke r\u00e6kker;<\/li>\n<li>eksporterede data kan indl\u00e6ses i en database af en anden version, og hvis eksporten er lavet i tekstformat, kan den ogs\u00e5 indl\u00e6ses i en anden database.<\/li>\n<\/ul>\n<p>\nDerfor bruges eksport prim\u00e6rt til opgaver s\u00e5som sikkerhedskopiering af sm\u00e5 tabeller (f.eks. ordb\u00f8ger) eller distribution af datas\u00e6t med den n\u00e6ste udgivelse af applikationen. <\/p>\n<p>Den mest anvendte metode til sikkerhedskopiering af databaser er dog at kopiere databasefiler.<\/p>\n<h3>\"Kold\" opbevaring af DB-filer<\/h3>\n<p>\nDen \u00e5benlyse id\u00e9 er at stoppe databasen og kopiere alle dens filer. En s\u00e5dan sikkerhedskopiering kaldes \"kold\". Metoden er ekstremt p\u00e5lidelig og simpel, men den har to \u00e5benlyse ulemper:<\/p>\n<ul>\n<li>Fra en \"kold\" backup kan man kun gendanne den tilstand af databasen, der var p\u00e5 tidspunktet for nedlukning; transaktioner, der er foretaget efter genstart af databasen, vil ikke v\u00e6re inkluderet i den \"kolde\" backup.<\/li>\n<li>Langt fra hver database har et teknologisk vindue, hvor databasen kan stoppes.<\/li>\n<\/ul>\n<p>\nHvis du er tilfreds med \"kold\" backup, skal du huske p\u00e5, at<\/p>\n<ul>\n<li>\"Kold\" kopi skal nogle gange ogs\u00e5 inkludere logs. Metoderne til at bestemme, hvilke logs der skal indg\u00e5 i \"kold\" kopien, er individuelle for hver database. For eksempel i Oracle skal man kopiere de s\u00e5kaldte online redo, som er et bestemt antal logfiler i en s\u00e6rlig mappe, selv n\u00e5r databasen er stoppet korrekt. I PostgreSQL skal alle logs gemmes fra den log, der indeholder det sidste kontrolpunkt, hvis information findes i kontrolfilen.<\/li>\n<li>Databasen kan indeholde ret store filer af tempor\u00e6re tabeller, som ikke n\u00f8dvendigvis skal inkluderes i backupen. Forresten er denne bem\u00e6rkning ogs\u00e5 korrekt for \"hot\" backup.<\/li>\n<\/ul>\n<p><\/p>\n<h3>\"Hot\" filbevaring<\/h3>\n<p>\nDe fleste backup af moderne databaser udf\u00f8res ved at kopiere databaser uden at stoppe dem. Her opst\u00e5r der flere problemer:<\/p>\n<ul>\n<li>Ved begyndelsen af kopieringen kan indholdet af databasen ikke stemme overens med indholdet af filerne, da en del information befinder sig i cachen og endnu ikke er skrevet til disken.<\/li>\n<li>Under kopieringen kan indholdet af databasen \u00e6ndre sig. Hvis der anvendes muterbare datalagringsstrukturer, \u00e6ndres indholdet af filerne, og ved brug af uforanderlige strukturer \u00e6ndres s\u00e6t af filer: nye filer vises, og gamle slettes.<\/li>\n<li>Da skrivning af data til databasen og l\u00e6sning af databasefiler ikke er synkroniseret, kan backupprogrammet l\u00e6se en ugyldig side, hvor den ene halvdel er fra den gamle version af siden, og den anden halvdel fra den nye.<\/li>\n<\/ul>\n<p>\nFor at sikre, at backupen er konsistent, har hver database et kommando, der angiver, at backupprocessen er startet. Syntaktisk kan denne kommando se forskellig ud: <\/p>\n<ul>\n<li>I Oracle er det en separat kommando ALTER DATABASE\/TABLESPACE BEGIN BACKUP;<\/li>\n<li>I PostgreSQL er det funktionen pg_start_backup();<\/li>\n<li>I Microsoft SQL Server og DB2 forberedes sikkerhedskopieringen implicit under udf\u00f8relsen af BACKUP DATABASE-kommandoen;<\/li>\n<li>I MySQL Enterprise, Cassandra og MongoDB forberedes det implicit af eksterne v\u00e6rkt\u00f8jer \u2013 hhv. mysqlbackup, OpsCenter og Ops Manager.<\/li>\n<\/ul>\n<p>\nP\u00e5 trods af syntaktiske forskelle ser forberedelsesprocessen til sikkerhedskopiering ens ud.<\/p>\n<p>S\u00e5dan ser forberedelsen til sikkerhedskopiering ud i databaser med \u00e6ndrede disktopologier, alts\u00e5 i alle traditionelle disk-baserede relationelle systemer:<\/p>\n<ol>\n<li>Tidspunktet for begyndelsen af sikkerhedskopieringen registreres; sikkerhedskopien skal indeholde databasejournaler fra dette tidspunkt.<\/li>\n<li>Der udf\u00f8res et kontrolpunkt, hvilket betyder, at alle \u00e6ndringer, der skete p\u00e5 datablade f\u00f8r det registrerede tidspunkt, skrives til disken. Dette sikrer, at journalerne f\u00f8r begyndelsen af sikkerhedskopieringen ikke vil v\u00e6re n\u00f8dvendige ved gendannelse.<\/li>\n<li>En s\u00e6rlig journaliseringsmodus aktiveres: hvis et datablade \u00e6ndres f\u00f8rste gang efter det er blevet indl\u00e6st fra disken, s\u00e5 i stedet for at skrive \u00e6ndringen af bladet ind i journalen, vil databasen skrive hele bladet. Under forberedelsesproceduren skrives alle blade ud til disken, hvilket betyder, at ved den f\u00f8rste \u00e6ndring vil blokken altid blive skrevet helt ind i journalen. Men hvis bladet igen skrives til disken under sikkerhedskopieringen, vil den n\u00e6ste \u00e6ndring ogs\u00e5 resultere i, at en fuld kopi af bladet fremg\u00e5r i journalen. Dette sikrer, at hvis filen med dataene under kopiering skulle blive beskadiget, vil anvendelsen af journalen g\u00f8re den korrekt igen.<\/li>\n<li>\u00c6ndring af headerne p\u00e5 datafilerne blokeres, det vil sige den del, hvis \u00e6ndringer ikke afspejles i journalerne. Dette sikrer, at headeren kopieres korrekt, og at journalerne derefter anvendes korrekt p\u00e5 datafilerne.<\/li>\n<\/ol>\n<p>\nN\u00e5r alle ovenst\u00e5ende procedurer er udf\u00f8rt, kan man kopiere datofiler ved hj\u00e6lp af operativsystemets v\u00e6rkt\u00f8jer \u2013 cp, rsync og andre. Aktivering af backup-tilstand reducerer databaseydelsen: for det f\u00f8rste \u00f8ges m\u00e6ngden af logs, og for det andet, hvis der opst\u00e5r fejl under backup-tilstanden, vil gendannelsen tage l\u00e6ngere tid, da headerne for datofiler ikke opdateres. Jo hurtigere backupen er afsluttet, desto bedre er det for databasen, s\u00e5 det er passende at anvende v\u00e6rkt\u00f8jer som snapshots af filsystemet eller BCV (breakable copy volume) i diskarrayet. Nogle databasesystemer (Oracle, PostgreSQL) giver administratoren mulighed for selv at v\u00e6lge metode til kopiering, mens andre (Microsoft SQL Server) tilbyder et interface til at integrere egne backupv\u00e6rkt\u00f8jer med filsystemernes eller SAN'ernes mekanismer.<\/p>\n<p>N\u00e5r backup er afsluttet, skal databasen s\u00e6ttes tilbage til normal tilstand. I Oracle g\u00f8res dette med kommandoen ALTER DATABASE\/TABLESPACE END BACKUP, i PostgreSQL med funktionen pg_stop_backup(), og i andre databaser med interne underprogrammer fra de relevante kommandoer eller eksterne tjenester.<\/p>\n<p>Her er et eksempel p\u00e5 den tidsm\u00e6ssige diagram for backup-processen:<\/p>\n<p><img decoding=\"async\" alt=\"Guide til backup af databaser\" src=\"\/wp-content\/uploads\/2020\/08\/4e74f865e9f35acec083b747da4449cf.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<ul>\n<li>Forberedelse til backup (begin backup) tager tid, undertiden betydelig. Selv n\u00e5r der bruges spejlede volumener eller filsystemer med snapshot-muligheder, vil backup-processen ikke v\u00e6re \u00f8jeblikkelig.<\/li>\n<li>Sammen med datofilerne skal loggene gemmes fra starttidspunktet for backup-forberedelsen til databasen er tilbage i normal tilstand.<\/li>\n<li>Man kan gendanne fra denne backup <b>p\u00e5 tidspunktet for, at databasen er tilbage i normal tilstand<\/b>. Gendannelse til et tidligere tidspunkt er ikke muligt.<\/li>\n<\/ul>\n<p>\nFor databaser, der bruger uforanderlige datastrukturer (snapshots af hukommelse, LSM-tr\u00e6er) er situationen enklere. Forberedelse til backup best\u00e5r af f\u00f8lgende trin:<\/p>\n<ol>\n<li>Data fra hukommelsen skrives til disk.<\/li>\n<li>En liste over filer, der indg\u00e5r i backupen, fastl\u00e6gges. Indtil backup-processen er afsluttet, er databasen forbudt at slette disse filer, selvom de ikke l\u00e6ngere er n\u00f8dvendige.<\/li>\n<\/ol>\n<p>\nN\u00e5r signalet om afslutning af sikkerhedskopieringen modtages, kan databasen med uforanderlige strukturer igen slette un\u00f8dvendige filer.<\/p>\n<h3>Gendan til punkt<\/h3>\n<p>\nSikkerhedskopieringen giver mulighed for at gendanne database til det tidspunkt, hvor kommandoen om tilbagevenden fra sikkerhedskopiering blev afsluttet. Imidlertid kan der opst\u00e5 en nedbrudssituation, som kr\u00e6ver gendannelse, n\u00e5r som helst. Opgaven med at gendanne database til et vilk\u00e5rligt tidspunkt kaldes 'gendannelse til punkt' (point-in-time recovery).<\/p>\n<p>For at muligg\u00f8re denne funktion skal databasen gemme logs fra det \u00f8jeblik, sikkerhedskopieringen er afsluttet, og under gendannelsen skal man forts\u00e6tte med at anvende logs p\u00e5 den gendannede kopi. N\u00e5r databasen er gendannet fra sikkerhedskopien ved afslutning af kopieringen, er tilstanden for databasen (filer og cachede sider) garanteret korrekt, s\u00e5 der er ikke behov for en s\u00e6rlig logging tilstand. Ved at anvende logs til det \u00f8nskede tidspunkt kan man opn\u00e5 database tilstanden p\u00e5 ethvert tidspunkt.<\/p>\n<p>Hvis hastigheden af gendannelsen af sikkerhedskopien begr\u00e6nses af diskens b\u00e5ndbredde, s\u00e5 er hastigheden for anvendelse af logs normalt begr\u00e6nset af processorens ydeevne. Hvis der foretages \u00e6ndringer i den prim\u00e6re database parallelt, s\u00e5 bliver alle \u00e6ndringer gendannet sekventielt \u2013 i den r\u00e6kkef\u00f8lge, de er l\u00e6st fra loggen. S\u00e5ledes afh\u00e6nger gendannelsestiden line\u00e6rt af, hvor langt gendannelsespunktet er fra afslutningspunktet for sikkerhedskopieringen. Derfor er det n\u00f8dvendigt at lave komplette sikkerhedskopier ret ofte - mindst \u00e9n gang om ugen for databaser med lille transaktionsbelastning og op til daglige sikkerhedskopier for h\u00f8jtbelastede databaser.<\/p>\n<h3>Inkrementel sikkerhedskopiering<\/h3>\n<p>\nFor at fremskynde gendannelsen til punkt vil man gerne have mulighed for at udf\u00f8re sikkerhedskopiering s\u00e5 ofte som muligt, men uden at optage for meget plads p\u00e5 diske og uden at belaste databasen med sikkerhedskopieringsopgaver.<\/p>\n<p>L\u00f8sningen p\u00e5 denne opgave er inkrementel sikkerhedskopiering, hvilket vil sige at man kun kopierer de datablade, der er \u00e6ndret siden den foreg\u00e5ende sikkerhedskopiering.<br \/>\nInkrementel backup giver kun mening for databaser, der bruger \u00e6ndrede datastrukturer.<\/p>\n<p>Inkrementet kan t\u00e6lles fra en fuld backup (kumulativ kopi) eller fra en hvilken som helst tidligere kopi (differential kopi). <\/p>\n<p><img decoding=\"async\" alt=\"Guide til backup af databaser\" src=\"\/wp-content\/uploads\/2020\/08\/10e3bb87445cb36693c7b5469d62eeaf.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDesv\u00e6rre findes der ikke en enhedsterminologi, og forskellige producenter bruger forskellige termer:<\/p>\n<p>Differential<br \/>\nKumulativ<\/p>\n<p>Oracle<br \/>\nDifferential<br \/>\nKumulativ<\/p>\n<p>PostgresPro<br \/>\nInkrementel<br \/>\n\u2014<\/p>\n<p>Microsoft SQL Server<br \/>\n\u2014<br \/>\nDifferential<\/p>\n<p>IBM DB2<br \/>\nDelta<br \/>\nInkrementel<\/p>\n<p>\nN\u00e5r der er inkrementelle kopier, ser processen for gendannelse til et punkt s\u00e5ledes ud:<\/p>\n<ul>\n<li>den seneste fulde backup, der blev lavet f\u00f8r gendannelsespunktet, gendannes;<\/li>\n<li>inkrementelle kopier gendannes oven p\u00e5 den fulde kopi;<\/li>\n<li>logfiler anvendes fra starten af backupen til gendannelsespunktet.<\/li>\n<\/ul>\n<p>\nTilg\u00e6ngeligheden af en kumulativ kopi fremskynder gendannelsesprocessen. For eksempel kr\u00e6ver gendannelsen af databasen til et punkt mellem T3 og T4 gendannelse af to inkrementelle kopier, mens gendannelsen efter T4 kun kr\u00e6ver \u00e9n.<br \/>\nDet er \u00e5benlyst, at st\u00f8rrelsen p\u00e5 \u00e9n kumulativ kopi er mindre end st\u00f8rrelsen p\u00e5 flere differentielle kopier, fordi nogle sider er blevet \u00e6ndret flere gange, og hver inkrementel kopi indeholder sin version af siden.<\/p>\n<p>Der er tre m\u00e5der at oprette en inkrementel kopi p\u00e5:<\/p>\n<ol>\n<li>oprette en fuld kopi og beregne forskellen fra den tidligere fulde kopi;<\/li>\n<li>analysere logfiler, oprette en liste over \u00e6ndrede sider og tage backup af siderne i denne liste;<\/li>\n<li>foresp\u00f8rge de \u00e6ndrede sider i databasen.<\/li>\n<\/ol>\n<p>\nDen f\u00f8rste metode sparer diskplads, men l\u00f8ser ikke opgaven med at reducere belastningen p\u00e5 databasen. Desuden, hvis vi har en fuld backup, er det meningsl\u00f8st at transformere den til en inkrementel, da gendannelsen af den fulde kopi er hurtigere end gendannelsen af den tidligere fulde kopi og inkrementet. Opgaven med at spare diskplads ved denne tilgang b\u00f8r bedst overlades til specielle komponenter med indbyggede deduplikeringsmekanismer. Dette kan v\u00e6re b\u00e5de specialiserede lagringssystemer (EMC DataDomain, HPE StorageWorks VLS, hele NetApp-serien) og softwareprodukter (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).<\/p>\n<p>Den anden og tredje metode adskiller sig i, hvordan de bestemmer listen over \u00e6ndrede sider. Analysering af logfiler er mere ressourcekr\u00e6vende, og der kr\u00e6ves kendskab til strukturen af logfilerne for at implementere det. At sp\u00f8rge selve databasen, hvilke sider der er \u00e6ndret, er enklere, men for det skal DBMS-kernen have funktionalitet til at spore \u00e6ndrede blokke (block change tracking).<\/p>\n<p>Funktionaliteten til inkrementel sikkerhedskopiering blev f\u00f8rst skabt i Oracle Recovery Manager (RMAN), som blev introduceret i Oracle 8i. Oracle implementerede straks sporing af \u00e6ndrede blokke, s\u00e5 der er ikke behov for at analysere logfiler.<\/p>\n<p>PostgreSQL sporer ikke \u00e6ndrede blokke, s\u00e5 v\u00e6rkt\u00f8jet pg_probackup, udviklet af det russiske firma Postgres Professional, identificerer \u00e6ndrede sider ved at analysere loggen. Dog tilbyder virksomheden ogs\u00e5 DBMS PostgresPro, som inkluderer udvidelsen ptrack, der sporer \u00e6ndringen af sider. N\u00e5r man bruger pg_probackup med DBMS PostgresPro, anmoder v\u00e6rkt\u00f8jet om \u00e6ndrede sider fra databasen \u2013 pr\u00e6cis som RMAN.<\/p>\n<p>Microsoft SQL Server, ligesom Oracle, sporer \u00e6ndrede sider, men kommandoen BACKUP tillader kun at lave komplette og kumulative sikkerhedskopier.<\/p>\n<p>I DB2 er der mulighed for at spore \u00e6ndrede sider, men det er som standard deaktiveret. Efter aktivering vil DB2 tillade at lave komplette, differentielle og kumulative sikkerhedskopier.<\/p>\n<p>En vigtig forskel mellem de v\u00e6rkt\u00f8jer, der er beskrevet i dette afsnit (bortset fra pg_probackup) og filbaserede sikkerhedskopieringsv\u00e6rkt\u00f8jer er, at de anmoder om sidebilleder fra databasen, i stedet for at l\u00e6se dataene fra disken selv. Ulempen ved denne tilgang er en lille ekstra belastning p\u00e5 databasen. Men denne ulempe opvejes med god samvittighed, fordi den l\u00e6ste side altid er korrekt, og derfor er der ikke behov for at aktivere en s\u00e6rlig logningsmode under sikkerhedskopieringen.<\/p>\n<p>Bem\u00e6rk igen, at tilstedev\u00e6relsen af inkrementelle kopier ikke annullerer kravene til at have logfiler til at gendanne til et vilk\u00e5rligt tidspunkt. Derfor bliver logfiler konstant omskrevet til et eksternt medium, og sikkerhedskopier, b\u00e5de komplette og\/eller inkrementelle, oprettes efter en fast tidsplan.<\/p>\n<p>Den bedste nuv\u00e6rende implementering af ideen omkring inkrementel sikkerhedskopiering er det programvare-hardware kompleks (i Oracle-terminologi \u2013 engineered system) Zero Data Loss Recovery Appliance \u2013 en specialiseret l\u00f8sning fra Oracle til sikkerhedskopiering af sin egen database. Kompleksen er en klynge <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/da\/server\/\"   title=\"servere\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1521\">servere<\/a> med et stort antal diske, hvorp\u00e5 der er installeret en modificeret version af Recovery Manager software og kan arbejde b\u00e5de med andre programvare-hardware kompleks fra Oracle (Database Appliance, Exadata, SPARC Supercluster) og med Oracle databaser p\u00e5 traditionel infrastruktur. I mods\u00e6tning til den \"almindelige\" RMAN implementerer ZDLRA konceptet \"evig inkrement\" (incremental forever). Systemet laver \u00e9n gang en fuld kopi af databasen, hvorefter der kun laves inkrementelle kopier. Yderligere RMAN-moduler giver mulighed for at kombinere kopier og lave nye fulde kopier ud fra inkrementelle. <\/p>\n<p>Til \u00e6re for de russiske udviklere skal det bem\u00e6rkes, at pg_probackup ogs\u00e5 kan kombinere inkrementelle kopier.<\/p>\n<p><img decoding=\"async\" alt=\"Guide til backup af databaser\" src=\"\/wp-content\/uploads\/2020\/08\/275b649ce74614c04410618a062dddbd.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI mods\u00e6tning til mange lignende sp\u00f8rgsm\u00e5l, har sp\u00f8rgsm\u00e5let \"hvilken sikkerhedskopieringsmetode er bedst\" et entydigt svar \u2013 den bedste metode er den native v\u00e6rkt\u00f8j til den anvendte databasesystem, der muligg\u00f8r inkrementel sikkerhedskopiering.<\/p>\n<p>For en databaseadministrator er valget af strategi for sikkerhedskopiering og integrationen af v\u00e6rkt\u00f8jer til sikkerhedskopiering af databaser i den virksomhedsm\u00e6ssige infrastruktur betydeligt vigtigere. Men disse emner ligger uden for rammerne af denne artikel.<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/516428\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430. \u041d\u043e \u0432\u0435\u0434\u044c \u0443 \u0432\u0430\u0441, \u043a\u0430\u043a \u0438 \u0443 \u043a\u0430\u0436\u0434\u043e\u0433\u043e, \u0435\u0441\u0442\u044c \u0440\u0435\u0437\u0435\u0440\u0432, \u0442\u0430\u043a \u0447\u0442\u043e \u043c\u043e\u0436\u0435\u0442\u0435 \u043d\u0435 \u0431\u0435\u0441\u043f\u043e\u043a\u043e\u0438\u0442\u044c\u0441\u044f. \u0421\u0442\u0430\u043d\u0438\u0441\u043b\u0430\u0432 \u041b\u0435\u043c, \u00ab\u0417\u0432\u0451\u0437\u0434\u043d\u044b\u0435 \u0434\u043d\u0435\u0432\u043d\u0438\u043a\u0438 \u0418\u0439\u043e\u043d\u0430 \u0422\u0438\u0445\u043e\u0433\u043e\u00bb \u0420\u0435\u0437\u0435\u0440\u0432\u043d\u044b\u043c \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u0441\u043e\u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u043a\u043e\u043f\u0438\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0433\u0434\u0435-\u0442\u043e \u0432\u043d\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u043c\u0435\u0441\u0442\u0430 \u0438\u0445 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f. \u0413\u043b\u0430\u0432\u043d\u043e\u0435 \u043d\u0430\u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u2013 \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u043e\u0441\u043b\u0435 \u0438\u0445 \u043f\u043e\u0442\u0435\u0440\u0438. \u0412 \u0441\u0432\u044f\u0437\u0438 \u0441 \u044d\u0442\u0438\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":92368,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-92367","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0443\u0442\u0435\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c \u043f\u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c\u0443 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-26T05:42:09+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-26T05:42:09+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Database Backup Guide | ProHoster","description":"\u2013 \u00c5h, intet tilflugtssted vil kunne modst\u00e5 et meteor nedslag.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0443\u0442\u0435\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c \u043f\u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c\u0443 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 | ProHoster","og:description":"\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-26T05:42:09+00:00","article:modified_time":"2020-08-26T05:42:09+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"92367","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:09:36","updated":"2026-02-09 16:50:36","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/92367","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=92367"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/92367\/revisions"}],"predecessor-version":[{"id":158765,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/92367\/revisions\/158765"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/92368"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=92367"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=92367"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=92367"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}