rkoski Mahdollisesti hyödyllistä tietoa

Paranoidin backup-resepti

Prologi

Toista viikkoa sitten työasemana käyttämäni koneen järjestelmäkiintolevy oli mennyt niin heikkoon kuntoon, että käyttöjärjestelmä kaatui. Kunto paljastui vasta uudelleenkäynnistyksessä, mutta levy oli temppuillut samaan tapaan jo aikaisemminkin. Olin silloin saanut levyn elvytettyä (e2fsck -cc auttoi) ja ottanut siitä kopion suurelle RAID6-pakalle. Tällä kertaa levy oli vielä pahemmassa jamassa.

Onneksi olin jo varautunut ja OpenSolaris-koneessa oleva SSD-levy oli jo tehtävänsä tehnyt ZFS:n cache-laitteena erilaisten testausten yhteydessä, joista olen kirjoittanut täällä aikaisemmin (katso kooste osoitteessa http://www.raimokoski.com/ZFS.php ). Vanha levy siis irti ja sen tilalle SSD-levy. Kone käyntiin Fedoran asennuslevyllä, rescue-moodiin, SSD-levylle samat osiot, kuin vanhalla, mutta pienempinä, tiedostojärjestelmien luonti ja täyttö varmuuskopiolta. Pientä säätöä aiheutti levyjen kokoero. Vanha oli puolitäysi 250-gigainen ja uusi 64. Ratkaisu oli korvata eniten tilaa vieviä hakemistopuita symbolisilla linkeillä RAID-pakalle kun niiden sisältö oli ensin siirretty sinne. 64 Gt on enemmän kuin tarpeeksi käyttöjärjestelmälle, joten ongelmaa ei ollut, vain järjestelyä. Päivitin sitten vielä Fedora 13:n 16:een. Ensin yummilla (yum --releasever=14 distro-sync, täysi ohjeistus osoitteessa http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum ) 14:ään ja sitten asennus-DVD:llä 16:een. Asennusohjelma kun ilmoitti, että vain kaksi versiota uudempaan onnistuu päivitys eli se vaati 14:n pohjaksi. Asennus-DVD on hyvä olla olemassa hätätilanteita varten. Ṕäivitys kyllä sujuisi yummilla kätevämmin, mutta kannatta sitä DVD:tä käyttää, jos sen on jo ladannut. Pientä jumppaa sai sormet ja kone eikä kaikki käynyt niin yksioikoisesti, kuin laiskuuttani kuvasin.

Vanha levy oli siis irti ja liitin sen toiseen koneeseen. Sillä oli kolme osiota, joista yksi swapille ja kaksi muuta kopioin työaseman RAID-pakalle seuraavasti:

dd_rescue /dev/sdc3 /rk7/mirrors/rk7sda3.img
dd_rescue /dev/sdc1 /rk7/mirrors/rk7sda1.img


dd_rescue on parannettu versio dd:stä, joka osaa käsitellä viallisia levyjä paremmin kuin alkuperäinen. Sekaannuksen vuoksi on vielä ddrescue, joka sekin on edeltäjäänsä parempi, mutta en muista kumpi uudemmista on parempi. Pääasia kuitenkin on, että vaativiin tehtäviin käyttää parannettua versiota.

Vanhan levyn tarina on periaatteessa vielä kesken, mutta lopputulos jo selvä. Ensin e2fsck -cc (bad block scan done using a non-destructive read-write test), joka meni läpi melko pienillä "vaurioilla", mutta nyt on ajossa "dd_rescue /dev/sdc /dev/sdc" ja tilanne näyttää pahentuneen toivottomaksi:

 

dd_rescue: (info): ipos:  76466312.0k, opos:  76466312.0k, xferd:  76466312.0k
                *  errs:  16794, errxfer:      8397.0k, succxfer:  76457920.0k
             +curr.rate:        0kB/s, avg.rate:      290kB/s, avg.load:  0.7%
             >xxxxxxxxxxxxx............................<  31%  ETA: 160:28:41
dd_rescue: (warning): read /dev/sdc (76466312.0k): Success!


Nuo x:t merkkaavat virheiden kohtia levyllä ja levyn alkukolmanneksesta viallisia sektoreita on jo löytynyt lähes 17 tuhatta. Oireilevaa levyä kannattaa elvyttää "e2fsck -cc":llä ja tai "dd_rescue /dev/sd<elvytettävä_levy> /dev/sd<elvytettävä_levy>":llä useamman kerran ennen kuin sitä uskaltaa uudelleen käyttää. Tosin tällä kertaa minua kiinnostaa eniten se, että tämä levy yleensä vielä toimii. Yleensä levyt sanovat sopimuksensa kokonaan irti melko pienen oireilun jälkeen. Tämä "toimii" ihan romunakin vielä.

Entäs sitten ne kuukauden aikana kerääntyneet tiedostot sen varmuuskopioinnin jälkeen? Kaikki tallessa. En detaljeja muista, mutta history-komennon tulosteesta poiminnat kertoo, että seuraavia olen puuhaillut:

mount -o loop,norecovery -t ext3 rk7sda3.img rk7sda3mnt
# Liitetään osion näköistiedosto, vaikka se olisi viallinen, jotta voidaan vilkaista, miltä sisältö näyttää ja sitten umount
cp -la rk7sda3.img rk7sda3.img.bk
# Ennen kuin näköistiedostoa muokataan, kopio talteen. "cp -l" tekee vain kovan linkin, huisin nopea tapa kopioida isoja tiedostoja
e2fsck rk7sda3.img
# Korjataan näköistiedoston tiedostojärjestelmän mahdolliset virheet


Kaikki tiedostot, joita osasin kaivata, olivat täysin kunnossa. Ei vahinkoa, aika paljon työtä ja hyvää harjoitusta.



Automatisoitu monitasoinen backup-järjestelmä

Tämä on ollut minulla tekeillä jo jonkin aikaa ja osittain vähän vahingossa. Työasemakoneessani, joka itseasiassa on samalla se tehokkain palvelin kotiverkossani, on 10 kpl 2 Tt kiintolevyjä RAID6-pakkana eli tallennustilaa on 16 Tt. OpenSolaris-koneessa on myös 10 kpl 2 Tt levyjä RAID6:sta vastaavana ZFS:n raidz2:na ja ajatuksena oli, että joko siirryn käyttämään OpenSolarista tiedostopalvelimena tai sitten käytän sitä backup-palvelimena.

Teoreettista taustapohdiskelua

Muitakin mahdollisuuksia on. Jos molemmissa koneissa käyttöjärjestelmänä olisi Linux, voisin käyttää DRBD:tä (Distributed Replicated Block Device, http://en.wikipedia.org/wiki/DRBD ) ja lopputulos olisi käytännössä RAID16. Linuxin RAID-toteutus mdadm käsittelee RAID-laitteita laitetiedostoina ja niitä voi ketjuttaa. RAID16 luodaan siten, että ensin tehdään kaksi yhtä suurta RAID6-pakkaa ja ne yhdistetään RAID1:ksi. Koska DRDB ei sovellu, voitaisiin käyttää iSCSI:ia ja tehdä OpenSolariskoneen jakamasta iSCSI-laitteesta ja Linux-koneen RAID6-pakasta RAID1-pakka ja jälleen lopputulos olisi RAID16.

RAID-laitteiden ketjuttaminen ja iSCSI tarjoavat muitakin mielenkiintoisia rakennelmia, kuten RAID66, jossa yksittäisissä koneissa olisi RAID6 ja ne muodostaisivat iSCSI-laitteina RAID6-pakan. Tämän tyyppisissä rakennelmissa ongelmaksi nousee kuitenkin hyvin pian verkon nopeus ja Linuxin mdadm:n "tyhmyys". Jos ylemmän tason RAID6 vaurioituu yhden koneen ongelmien takia, voi pariteettien tarkistaminen kestää useita päiviä tai jopa viikkoja, kun oireillut kone palautetaan ylemmän tason RAID6-pakan jäseneksi. Toinen ongelma olisi, että ylimmän tason RAID-pakan muodostava kone olisi selvästi pullonkaula sekä prosessoritehonsa että verkkoliitynnän kapasiteetin takia. Kaikki prosessointi ja verkkoliikenne kulkisi yhden koneen kautta. Se pitäisi ilmiselvästi kahdentaa eli RAID66 ei ole järkevä, toteutustapa pitäisi olla RAID-166. Se ei kuitenkaan poistaisi pullonkaula-ongelmaa.

Verkon yli toteutettava pariteetillinen RAID ei siis ole järkevä. Paremman ratkaisun tarjoaa hajautettu tiedostojärjestelmä. Niitä on eri tyyppisiä ja parhaan suorituskyvyn sekä vikasietoisuuden yhdistävät hajautetut, rinnakkaiset ja vikasietoiset tiedostojärjestelmät ( http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_parallel_f... ). Niistä kiinnostavimmalta vaikuttaa Lustre, koska se alkuaan oli tarkoitettu ZFS:n "isoveljeksi" eli vastassa ei pitäisi olla ahdistavia kokorajoituksia. Linux Journalissa oli siitä äskettäin artikkeli: http://www.linuxjournal.com/content/lustre-distributed-filesystem?page=0,0 .

Lustre kiertää pullonkaulaongelmaa keskittämällä vain metadatan yhteen palvelimeen (metadata server, MDS), kun taas itse tiedostot ovat hajautettu useammalle palvelimelle (object storage server, OSS), eivätkä ne kulje MDS:n kautta. Lustre ei suoraan ota kantaa redundanssiin, mutta tukee HA (High Availability, yksinkertaistaen varakone, kahdentaminen) -ratkaisuja. MDS-parin pitää olla aktiivi-passiivi-tyyppinen, mutta OSS-parit voivat olla aktiivi-aktiivi-tyyppisiä.

Eräs tapa ymmärtää Lustren rakennetta on ajatella sitä fiksumpana tapana ketjuttaa RAID-laitteita samaan tapaan kuin zpool on fiksumpi tapa toteuttaa RAID yksittäisessä koneessa. Lähdetään rakentamaan Lustre-klusterin RAID-numerosarjaa. MDS on kahdennettu eli saadaan 1 eli peilaus. OSS:t ovat vain toistensa jatkeena eli saadaan 0. OSS-parit ovat taas 1. Yksittäisessä OSS:ssä levyt ovat RAID-6 eli viimeinen numero on 6 ja koko sarjasta muodostuu RAID-1016. Melkoinen rakennelma. Lustre onkin käytössä kolmessa maailman nopeimmassa supertietokoneessa ja puolessa top500-listan 30:stä nopeimmasta koneesta.

Takaisin maan pinnalle

Kaikkea kivaa olisi tarjolla, mutta kotikäyttöön ei ihan täysimittaista konesalia ole tarkoitus rakentaa, vaan backup-järjestelmä. Snapshotit ovat ZFS:ssä kiva ominaisuus, mutta Linuxissa sen tarjoaa käytännössä vain LVM, joka muuten on mielestä todella suolesta. Kovilla linkeillä pystyy kuitenkin tekemään hyvin samankaltaisen rakennelman. Tämän skriptin varhaisempi versio esiteltiin jo ZFS-sarjassa:

#!/bin/bash
# /mirrors on suuri data-tiedostojärjestelmä
# muuta se järjestelmääsi sopivaksi
if [ ! `mount | grep /mirrors >/dev/null` ]
then
# vaikutusta vain 1. ajokerralla
  mkdir -p /mirrors/bk/current > /dev/null
  cd /mirrors/bk
  rm -rf 30
  for i in `seq 29`
  do
    mv $((30-$i)) $((31-$i)) > /dev/null
  done
  cp -al current 1
# cp-komento ei muuta kohdehakemiston päiväystä, joten
  touch 1
# muuta lähde- ja kohdehakemistoja tarpeen mukaan
  rsync -axH --delete /      current/sda3
  rsync -aH --delete  /boot  current/sda1
  echo Backup done at `date`
fi


Kun skriptiä on ajettu päivittäin kuukausi, on viimeisin backup-hakemisto nimellä current, mutta siellä on "aitoina" tiedostoina vain uudet tai muutetut tiedostot. Alla kaksi du:n tulostetta, aito levytilan käyttö ja näennäinen:

[root@rk7 bk]# du -sh *
32G     1
4,5G    2
8,9G    3
2,7G    4
4,1G    5
17G     current
[root@rk7 bk]# du -shl *
33G     1
32G     2
31G     3
30G     4
30G     5
35G     current


OpenSolariskoneelle päätin kopioida vain kerran viikossa, mutta skriptiä ei tarvitse muuttaa, jos haluan muuttaa aikataulutusta. Erikoishuomiota vaatii systeemilevyn varmistushakemisto. ZFS ei tarvitse kovilla linkeillä tehtyä snapshot-toteutusta, joten vain viimeisin versio kopioidaan.

#!/bin/bash
if [ ! `mount | grep /rk6 >/dev/null` -a ! `mount | grep /mirrors >/dev/null`  ]
then
  cd /mirrors
  ls -lR > ls_-lR
  rsync -aH --delete --exclude=/mirrors/bk/ /mirrors /rk6 2>/dev/null
  rsync -aH --delete /mirrors/bk/current /rk6/mirrors/bk 2>/dev/null
fi


Ja lopuksi vielä /etc/crontab-lisäykset:

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  *  command to be executed


02 5 * * * root /usr/local/bin/sysbackup
32 5 * * 0 root /usr/local/bin/mirrorbackup



Nyt saa levyt yrittää ryppyillä, nih!

Piditkö tästä kirjoituksesta? Näytä se!

0Suosittele

Kukaan ei vielä ole suositellut tätä kirjoitusta.

NäytäPiilota kommentit (5 kommenttia)

Käyttäjän rkoski kuva
Raimo Koski

Nyt oli admin-setä hyvin vihainen ;)

Käyttäjän arisuhonen kuva
Ari Suhonen

Luulin ensin, että olet soittanut Paranoidin takaperin. Sorry, väärinymmärrys. PS. Älä koskaan tee sitä. ;)

Käyttäjän juhauronen kuva
Juha Uronen

Se on sinun syysi Ari että nyt minun on pakko joko
A) Soittaa itse Paranoid takaperin
tai
B)Pilata alkuperäinen divaristä löydetty LP-levy soittamalla sitä sormivoimin takaperin josko löytys sanomaa

(Niin ja anteeksi öff-stöpic)

Käyttäjän rkoski kuva
Raimo Koski

Kirjoitin koko jutun hämäyksenä, jotta lopussa voisin kirjoittaa pakollisen Monty Python viittauksen, nih! http://www.youtube.com/watch?v=QTQfGd3G6dg

Käyttäjän arisuhonen kuva
Ari Suhonen

Meinasin jo sanoa, että hyvästi yöunet, mutta puhuttiinko tuossa videossa jostakin itsekunnioituksen tapaisesta? Mikäli, niin kenties on kohta aika ryömiä johonkin koloon miettimään sitä. Nih!

Tämän blogin suosituimmat

Mainos

Netin kootut tarjoukset ja alennukset