9.10. Còpia de seguretat

Making backups is one of the main responsibilities of any administrator, but it is a complex subject, involving powerful tools which are often difficult to master. The importance of backups cannot be stressed enough, though. Backups are also not to be confused with the availability of data. Both can complement each other, but they are essentially different.

Hi ha molts programes, com ara amanda, bacula o BackupPC. Aquests són sistemes client/servidor amb moltes opcions, la configuració de les quals és bastant difícil. Alguns d'ells proporcionen interfícies web fàcils d'utilitzar per mitigar això. Per a sistemes que no són d'empreses, els administradors podrien voler considerar rsnapshot o rdiff-backup. Els usuaris poden crear fàcilment còpies de seguretat dels seus sistemes de fitxers amb timeshift, fsarchiver, duplicity, o fins i tot dd.

Debian conté dotzenes d'altres programaris de còpia de seguretat que cobreixen tots els casos d'ús possibles, com podeu confirmar fàcilment amb apt-cache search copy.

En lloc de detallar-ne uns quants, aquesta secció presentarà els pensaments dels administradors de Falcot Corp quan van definir la seva estratègia de còpies de seguretat.

GOING FURTHER Backup Strategies

The backup strategy for each company or person is different. It depends on many factors. A good starting point is the 3-2-1 rule, though. It is easy and logical. One should have at least three instances of the data, the original and two backups at least. The backups should be stored on at least two different media. And most importantly, one of the backups should be hosted externally (and actually, preferably offline). A fire, a compromise, or a technical quirk should be be able to destroy all backups.

En el Falcot Corp, les còpies de seguretat tenen dos objectius: recuperar els arxius eliminats erròniament, i restaurar ràpidament qualsevol ordinador (servidor o escriptori) el disc dur del qual ha fallat.

9.10.1. Còpies de seguretat amb `rsync`

Havent-se descartat les còpies de seguretat en cinta per massa lentes i costoses, les dades es desaran en discos durs en un servidor dedicat, on l'ús de programari RAID (vegeu Secció 12.1.1, «RAID per software») protegirà les dades de fallades del disc dur. Els ordinadors d'escriptori no estan suportats individualment, però s'indica als usuaris que el seu compte personal al servidor d'arxius del seu departament sí que ho està. L'ordre rsync (del paquet del mateix nom) s'utilitza diàriament per fer una còpia de seguretat d'aquests diferents servidors.

TORNAR A LES BASES L'enllaç dur, un segon nom per a un fitxer

Un enllaç dur, en contraposició a un enllaç simbòlic, no es pot diferenciar del fitxer enllaçat. Crear un enllaç dur és essencialment el mateix que donar un segon nom a un fitxer existent. Per això l'eliminació d'un enllaç dur només elimina un dels noms associats amb el fitxer. Mentre un altre nom encara estigui assignat a l'arxiu, les dades que hi ha queden presents al sistema de fitxers. És interessant observar que, a diferència d'una còpia, l'enllaç dur no ocupa un espai addicional en el disc dur.

Es crea un enllaç dur amb l'ordre ln objectiu enllaç. L'enllaç és llavors un nom nou per al fitxer objectiu. Els enllaços durs només es poden crear en el mateix sistema de fitxers, mentre que els enllaços simbòlics no estan subjectes a aquesta limitació.

L'espai de disc dur disponible fa prohibitiva la implementació d'una còpia de seguretat diària completa. Per tant, l'ordre rsync va precedida per una duplicació del contingut de la còpia de seguretat anterior amb enllaços durs, que evita l'ús de massa espai de disc dur. El procés rsync només substitueix els fitxers que s'han modificat des de l'última còpia de seguretat. Amb aquest mecanisme es pot mantenir un gran nombre de còpies de seguretat en una petita quantitat d'espai. Com que totes les còpies de seguretat estan immediatament disponibles i accessibles (per exemple, en diferents directoris d'un espai compartit en xarxa), es poden fer comparacions entre dues dates donades.

Aquest mecanisme de còpia de seguretat s'aplica fàcilment amb el programa dirvish. Utilitza un espai d'emmagatzematge de còpia de seguretat («bank» en el seu vocabulari) on col·loca còpies amb marques temporals de conjunts de fitxers (aquests conjunts s'anomenen «vaults» en la documentació de dirvish).

La configuració principal és al fitxer /etc/dirvish/master.conf. Defineix la ubicació de l'espai d'emmagatzematge de la còpia de seguretat, la llista de voltes (o «vaults») per gestionar, i els valors per defecte per a la caducitat de les còpies de seguretat. La resta de la configuració es troba als fitxers banc/volta/dirvish/default.conf i conté la configuració específica per al corresponent conjunt de fitxers.

Exemple 9.3. El fitxer /etc/dirvish/master.conf

bank:
    /backup
exclude:
    lost+found/
    core
    *~
Runall:
    root    22:00
expire-default: +15 days
expire-rule:
#   MIN HR    DOM MON       DOW  STRFTIME_FMT
    *   *     *   *         1    +3 months
    *   *     1-7 *         1    +1 year
    *   *     1-7 1,4,7,10  1

El paràmetre bank indica el directori en el qual s'emmagatzemen les còpies de seguretat. El paràmetre exclude permet indicar els fitxers (o tipus de fitxers) que s'exclouran de la còpia de seguretat. Runall és una llista de conjunts d'arxius a fer una còpia de seguretat amb una marca de temps per a cada conjunt, que permet assignar la data correcta a la còpia de seguretat, en cas que la còpia de seguretat no s'activi precisament en el moment assignat. Heu d'indicar un temps just abans del temps real d'execució (segons /etc/cron.d/dirvish). Finalment, els paràmetres expire-default i expire-rule defineixen la política de caducitat de les còpies de seguretat. L'exemple anterior manté per sempre còpies de seguretat que es generen el primer diumenge de cada trimestre, elimina després d'un any les del primer diumenge de cada mes, i després de 3 mesos les d'altres diumenges. Altres còpies de seguretat diàries es mantenen durant 15 dies. L'ordre de les regles és important, ja que dirvish utilitza l'última regla aplicable, o la regla expire-default si no hi ha cap altra regla expire-rule que coincideixi.

Exemple 9.4. El fitxer /backup/root/dirvish/default.conf

client: rivendell.falcot.com
tree: /
xdev: 1
index: gzip
image-default: %Y%m%d
exclude:
    /var/cache/apt/archives/*.deb
    /var/cache/man/**
    /tmp/**
    /var/tmp/**
    *.bak

L'exemple anterior especifica el conjunt de fitxers per fer-ne una còpia de seguretat: aquests són fitxers a la màquina rivendell.falcot.com (per a la còpia de seguretat de dades locals, simplement cal especificar el nom de la màquina local com indica hostname), especialment els de l'arbre arrel (tree: /), excepte els llistats a exclude. La còpia de seguretat es limitarà al contingut d'un sistema de fitxers (xdev: 1). No inclourà arxius d'altres punts de muntatge. Es generarà un índex de fitxers desats (index: gzip), i la imatge s'anomenarà d'acord amb la data actual (image-default: %Y%m%d).

Hi ha moltes opcions disponibles, totes documentades a la plana del manual dirvish.conf(5). Un cop aquests fitxers de configuració estan a punt, s'ha d'inicialitzar cada conjunt de fitxers amb l'ordre dirvish --vault vault --init. A partir d'aquí la invocació diària de dirvish-runall crearà automàticament una nova còpia de seguretat just després d'haver eliminat les que hagin caducat.

9.10.2. Restauració de màquines sense còpies de seguretat

Els ordinadors d'escriptori, que no estan ssuportats, seran fàcils de reinstal·lar a partir dels DVD-ROM o llapis USB personalitzats preparats amb simple-cdd (vegeu Secció 12.3.3, «Simple-CDD: la solució tot-en-un»). Atès que així es fa una instal·lació des de zero, es perdrà qualsevol personalització que es pugui haver fet després de la instal·lació inicial. Això ja està bé perquè tots els sistemes estan connectats a un directori central LDAP per a comptes d'usuari i la majoria de les aplicacions d'escriptori estan preconfigurades gràcies a dconf (vegeu Secció 13.3.1, «GNOME» per a més informació sobre això).

Els administradors de Falcot Corp són conscients de les limitacions de la seva política de còpies de seguretat. Com que no poden protegir el servidor de còpies de seguretat com una cinta en una caixa forta a prova de foc, l'han instal·lat en una sala separada perquè un desastre com ara un incendi a la sala del servidor no destrueixi còpies de seguretat juntament amb tota la resta. A més, fan una còpia de seguretat incremental en DVD-ROM una vegada a la setmana — només s'hi inclouen els fitxers que s'han modificat des de l'última còpia de seguretat.

ANANT MÉS ENLLÀ Còpies de seguretat dels serveis LDAP i SQL

Molts serveis (com les bases de dades SQL o LDAP) no poden ser recolzats simplement copiant els seus fitxers (tret que estiguin adequadament interromputs durant la creació de les còpies de seguretat, fet que sovint és problemàtic, ja que estan destinats a estar disponibles en tot moment). Com a tal, és necessari utilitzar un mecanisme d'exportació per crear un “bolcat de dades” del que se'n pot fer una còpia de seguretat. Sovint són força grans, però es comprimeixen bé. Per reduir l'espai d'emmagatzematge necessari, només es pot emmagatzemar un fitxer de text complet per setmana, i un diff cada dia, que es crea amb una ordre del tipus diff fitxer_d_ahir fitxer_d_avui. El programa xdelta produeix diferències incrementals dels bolcats binaris.