page header photo

augustus 2016 Archieven

Ik hield van Amanda: ik kon er mee lezen en schrijven.


Geplaatst door gait op | Permanente link | Categorie: Systeembeheer, Tips and Tricks | Reacties: 0

Maar ja, voor dat ik het wist vertrok ze en moest ik het met een ander doen.

Via via kreeg ik een date met Rsnapshot en voorwaar: dat werd een waardige vervanger. Dat Amanda vertrok komt hier aan de orde.

Amanda stond voor Advanced Maryland Automatic Network Disk Archiver. Ze maakte in een client/server-model dumps van verschillende client-hosts naar de opslag op de dump-server. Ze deed alles heel gelijkmatig qua tijdsbesteding want na verloop van tijd duurde het maken van een dump —een mengsel van volledige en incrementele dumps— elke nacht ongeveer even lang. Amanda was daarbij zuinig qua data: er werden slechts delta's 'overgehaald'. Dat kon per SSH —naar wens met een forced command— of met haar eigen protocol. Ze deed het met tape-drives en natuurlijk ook met tapewisselaars.

Voor het 'terughalen' van bestanden bood Amanda een interactief commando waarbij je een locatie (padnaam) en een tijdvenster kon instellen. Die interactie was vergelijkbaar met de dump/restore-combo afkomstig uit 4.2BSD. Zodoende kon je eerst vastleggen wat er teruggehaald moest worden en daarna ging Amanda voor je aan de slag. Daarbij werd zonodig om een andere tape gevraagd.

Er werden zogenaamde holdingdisks gebruikt voor tijdelijke opslag: aldus werd het ophalen van data gescheiden van het opslaan op het definitieve medium.

Toen de tapewisselaar het begaf hebben we de schijven niet alleen gebruikt voor de tijdelijke maar ook voor de permanente opslag: die schijven heetten dan 'virtuele tapes' en het wisselen der tapes werd uitbesteed aan het commando ln -s

Maar ja, ook een schijf kan kapot. Sterker: het hele systeem viel uit! We moesten plotseling overstappen op iets anders.

Dat is een ander server geworden met als dumpoplossing Rsnapshot: in vergelijking met Amanda een stuk minder veelzijdig maar voor een niet zo grote site ben je daarmee ook goed af.

Rsnaphot is niet veel meer dan een schil om rsync, waarbij die schil voornamelijk bestaat uit de configuratie van de client hosts, de specificatie van (niet) te dumpen data, het hanteren van de bewaartermijnen en het maken van logs.

Uitgaande van de standaardconfiguratie wordt er 4 maal per dag (hourly), 7 maal per week (daily), 4 maal per maand (weekly) en 12 maal per jaar (monthly) gedumpt.

Rsync wordt dus gebruikt: je beschikt daardoor telkens over een complete directory-boom waarin identieke bestanden slechts eenmaal aanwezig zijn: ze hangen met een of meer harde links in de boom.

Je kunt terug in de tijd door het juiste pad te bewandelen en met wat handige wildcards kun je ook de tijdstempels van vorige versies van je bestand zien.

Doe je een du op al die periodieke directories (tegelijk) dan zie je aan het ruimtebeslag van de nieuwste directory de huidige hoeveelheid data die ook op de client staat en bij de rest van de directories hoeveel er in de tussentijd veranderde, de terugwaartse delta.

Als je de nieuwste directory weggooit levert dat doorgaans niet veel vrije ruimte op: de nieuwe bestanden zijn weg, ongewijzigde bestanden blijven staan.


Op basis van deze informatie is toch wel eens flink op ruimte bespaard.

Het is niet voor niets gebruikelijk logbestanden te roteren. Dit mes snijdt aan twee kanten: de historie wordt beperkt, de historische bestanden worden naar wens gegezipt en je blijft niet zitten met een enorm groot logbestand dat telkens opnieuw gedumpt wordt.

In het onderhavige geval werd er ruimhartig gelogd op een niet-standaard locatie die ontsnapte aan de rotatie. Dat is natuurlijk rechtgezet.


Omdat de overstap naar Rsnapshot onder druk gebeurde worden de lokale clients met NFS geholpen (voor de remote clients wordt deels de bestaande SSH-configuratie gebruikt): de clients exporteren de te dumpen directories en die worden op de dumphost gemount in een bepaalde directory te weten

/hosts_nfs/<client>/

De directory met alle mountpoints

/hosts_nfs/

wordt in z'n geheel gedumpt. Aldus komt het configureren van een nieuwe lokale client neer op het exporteren op de client en het mounten op de dumphost.

Bedenkt dat er exports zijn waarbinnen op de client weer gemount is (geneste mounts). Om te voorkomen dat er van alles mis gaat indien niet alle NFS-mounts in de enige juiste volgorde beschikbaar komen is er iets speciaals gedaan.

nijmegen1:/           on /hosts_nfs/nijmegen1/ROOT
nijmegen1:/usr        on /hosts_nfs/nijmegen1/USR
nijmegen1:/usr/atcomp on /hosts_nfs/nijmegen1/usr/atcomp
nijmegen1:/usr/local  on /hosts_nfs/nijmegen1/usr/local

De aparte behandeling van / ligt voor de hand en onder /usr zitten ook mounts: vandaar / op ROOT en /usr op USR

Overigens worden de mounts in de gaten gehouden door onze Nagios-monitoring: check_nfs zoekt uit of alle NFS-mount in /etc/fstab actief zijn.

Het viel misschien op dat ik ergens in dit verhaal overstapte van verleden naar heden. Ondanks de flitsscheiding verlies ik Amanda niet uit het oog. Ze is zeker bijdetijds, er is veel ontwikkeling en een zeer actieve mailinglist. De schrijver van deze lezenswaardige blog komt regelmatig voorbij.

Dit alles vindt slechts on-site plaats: als de bom valt zijn we alles kwijt. Ergo: off-site opslag is nodig. Dat gebeurt wel maar dat komt in een volgende bijdrage aan de orde.