Còpies de seguretat de Postgres III

De Wikijoan
Dreceres ràpides: navegació, cerca

Contingut

Arxivat continu i Recuperació en un Punt del Temps (Point-In-Time-Recovery, PITR)

basat en la documentació oficial de Postgres: 24.3. Continuous Archiving and Point-In-Time Recovery (PITR)

El Postgres sempre fa una còpia de l'activitat que va succeïnt a la bd (Write Ahear Log, WAL), en el subdirectory data/pg_xlog. Aquest log descriu cada canvi en els fitxers de dades de la bd. El log existeix bàsicament per motius de seguretat: si el sistema té un desastre, la bd es pot restaurar consistentment aplicant els log's des de l'últim checkpoint. Això passa tant si treballem en mode arxivat com si no. A més a més, l'existència dels log fa possible una tercera estratègia per fer còpies de seguretat de les bases de dades: es tracta de combinar un backup a nivell de fitxers amb un backup dels fitxers de WAL. D'aquesta manera estem aconseguint fer còpies en calent. En la terminologia Oracle diem que treballem en mode arxivat. Si es necessita fer una recuperació es restaura la còpia de fitxers de sistema i s'apliquen tots els fitxers de WAL per tal de situar la base de dades fins al punt previ al desastre.

És l'únic sistema que garanteix còpies en calent i que és 24x365. Com sempre, abans d'entrar en producció, el DBA haurà de testejar simulacres de còpies i recuperació, d'aquesta manera de procedir, que també s'anomena backup online.

Beneficis:

Contres:

Posta en marxa de l'arxivat WAL

PostgreSQL produeix de forma indefinida llargues seqüències de WAL. El sistema físicament divideix la seqüència en fitxers, els fitxers de segment, de 16Mb. Quan no treballem en mode arxivat hi ha uns pocs segments, que es recicla el nom i es reescriuen de forma cíclica (anàlogament al que veiem en Oracle). Els checkpoints provoquen un salt de fitxers de segment.

Quan treballem en mode arxivat, el que volem es guardar en algun lloc els segments de fitxer abans de que es matxaquin. En aquest punt PostgreSQL no fa cap suposició de com i on es guardaran els arxius, i es deixa a lliure el.lecció del DBA, i es defineix en el fitxer postgresql.conf, en el paràmetre de configuració archive_command (recordem que el que estem explicant val tant per Postgre sobre Windows com sobre Linux).

archive_command = 'cp -i %p /mnt/server/archivedir/%f < /dev/null' #Linux
archive_command = 'copy %p C:\\copies\\%f' #Windows

on %p es reemplaça pel fitxer incloent la ruta, i %f només el nom del fitxer En aquests dos casos, la comanda d'arxivat és un copy més o menys simple, però podem tenir un script complexe que realitzi compressió, comprovacions, etc.

La comanda d'arxivat només s'invoca quan es completa un segment de WAL. Si el servidor genera poc trànsit, pot passar temps abans no s'arxiva el segment. Podem provocar l'obigació d'arxivar com a mínim en un determinat temps amb el paràmetre archive_timeout.

També podem forçar manualment un canvi de segment amb pg_switch_xlog:

postgres# select pg_switch_xlog();

1r pas. Fem el Backup Base

El procediment per fer el backup inicial és relativament simple

1. Primer ens assegurem que l'arxivat WAL està habilitat i en funcionament (fitxer posgresql.conf. Si es modifica, s'ha de reiniciar el servei)

2. Ens connectem a la bd com a superusuari (postgres), i executem la comanda

SELECT pg_start_backup('label');

on label és la cadena que vulguis posar, que identifica de forma unívoca el procés de backup. pg_start_backup crea un fitxer de backup petit, anomenat backup_label, en el directori del cluster (/data) amb informació sobre el backup (es pot obrir en mode text per veure el contingut).

3. Realitzar el backup pròpiament dit, és a dir, copiar el directori /data a una carpeta del disc (per exemple, C:/data). La carpeta /pg_xlog no cal copiar-la, o si es copia, més endavant no l'haurem de restaurar, perquè és una informació de log que haurà quedat obsoleta. (per no equivocar-se en el procés de restauració, més val no copiar-la) Fixem-no que no és necessari ni tampoc desitjable aturar la base de dades mentre es fa el copiat. D'altra banda, encara que els fitxers estiguin en ús, això no ens impedirà fer una còpia en calent. Si mentre es fa la còpia hi ha activitat a la base de dades, aquests canvis es guarden en els logs de WAL. Estem fent una còpia en calent

4. Connectats com a superusuaris, executem la comanda

SELECT pg_stop_backup();

Això implica la finalització del backup i fa un switch automàtic al següent segment de WAL. La raó del switch és perquè el segment WAL on s'estava escrivint durant el procés de backup s'arxivi immediatament.

5. Un cop s'han arxivat els segments de WAL utilitzats durant el backup, ja està. El fitxer identificat com a pg_stop_backup és l'últim segment que es necessita arxivar. L'arxivat d'aquests fitxers és automàtic, doncs hem configurat el paràmetre archive_command. De totes maneres, comprovar que s'han arxivat bé al directori C:/copies

Recuperació utilitzant un Backup d'Arxivat Continu

Hem tingut un desastre, i hem de fer una recuperació. Aquest és el procediment. 1. Tancar el servidor, si és que està en marxa

2. Si tenim espai de disc, copiar el directori /data i els espais de taula (per ex, a C:/data2). Si no tens suficient espai, com a mínim copia el contingut del subdirectori pg_xlog, doncs conté tots els logs que encara no es van arxivar quan el sistema es va parar

3. Neteja tots els fitxers i subdirectoris de /data i dels directoris arrel dels espais de taula.

4. Restaura els fitxers de la base de dades des del directori on vam fer la còpia (per ex, C:/data). (En el cas del sistema Linux, compte amb els permisos)

5. Elimina els fitxers presents en /pg_xlog (potser ja no els havíem copiat, són obsolets per a la restauració). Recrea la carpeta /pg_xlog i la subcarpeta /archive_status

6. Si en el pas 2 vas copiar fitxers de segment WAL no arxivats, ara és el moment de restaurar-los: copia'ls a /pg_xlog. (És millor copiar que moure)

7. Crea el fitxer recovery.conf en el directori del cluster (/data). En el fitxer ficarem com a mínim la línia restore_command (veure més avall). També pots modificar temporalment el fitxer pg_hba.conf per impedir que els usuaris es connectin mentre s'està fent la recuperació.

8. Engega el servidor. El servidor es posa en 'mode de recuperació', i llegeix de la carpeta on tenim els WAL arxivats (C:/copies). Un cop finalitzat el procé, el servidor renombra recovery.conf a recovery.done. És la garantia que el procés ha estat correcte. Ja podem continuar treballant.

9. Inspeccina el contingut de la base de dades per assegurar-nos de què tot ha anat bé. Si no, torna al punt 1. Torna a modificar el fitxer pg_hba.conf, si és el cas

En el fitxer recovery.conf tindrem les comandes que indiquen com ha de ser el procés de recuperació. En el cas més simple, tindrem una sola línia:

restore_command = 'copy C:\\copies\\%f %p'  #windows

Normalment es recuperen tots els segments de WAL disponibles, que significa recuperació fins al final (fins al punt que es va produir el desastre). Però també és possible recuperar fins a un determinat punt en el temps (per exemple, just abans que s'esborrés la taula FACTURA). Per fer-ho, hem d'especificar el punt de stop a recovery.conf (recovery taget). Ho podem fer especificant el dia i hora o bé el ID de la transacció.

El nostre fitxer recovery.conf quedarà de la següent manera:

restore_command = 'copy C:\\copies\\%f %p' #windows
recovery_target_time = '2008-04-24 20:22:00'

D'aquesta manera aconsegueixo fer una recuperació fins al punt de temps especificat. Els paràmetres del fitxer recovery.conf són:

Exemple de fitxer recovery.conf més complet que el que hem utilitzat.

Pràctica

1. Tenim les taules EMPLEAT, CLIENT, FACTURA i DETALL, amb les que operem habitualment

2. Treballem en mode arxivat. Fem una còpia completa, tal com s'ha comentat, a les 12:00. Anotem quina és la factura actual. Per ex, la fact núm. 320

3. Operem amb la base de dades. Es generen factures. per exemple, de la 321 a la 350.

4. Per error s'eborren totes les factures. DROP TABLE DETALL, DROP TABLE FACTURA. A les 13:00

5. Recuperem, segons el procediment explicat, la bd. Si ha funcionat, veurem que tenim totes les factures.

6. Fem ara una recuperació parcial, fins les 12:01. Si funciona, veiem que només tenim les factures fins la 320


creat per Joan Quintana Compte, abril 2009

Eines de l'usuari
Espais de noms
Variants
Accions
Navegació
IES Jaume Balmes
Màquines recreatives
CNC
Informàtica musical
joanillo.org Planet
Eines