Rdiff-backup

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(Backup megoldások)
a (Backup megoldás rdiff-backup használatával lapot átneveztem Rdiff-backup névre: Rövidítsünk a címen)
 
(2 szerkesztő 16 közbeeső változata nincs mutatva)
1. sor: 1. sor:
= Bevezető =
+
Írta: Andocsi László, 2009. december.
   
== Biztonsági mentés fogalma, célja ==
+
Ez a szócikk az <tt>rdiff-backup</tt> nevű [[backup]]-megoldást mutatja be. Javaslom, hogy mielőtt elolvasod, nézd meg a [[Backup]] szócikket is, mert néhány ott leírt fogalmat itt csak használni fogok.
* A backup-megoldás elsődleges célja biztonsági mentés készítése a rendszer adott állapotáról
 
* A biztonsági mentés alapvető védelmet jelent bizonyos hardver- és szoftverhibák ellen
 
** Emberi hibák ellen is véd (pl. a RAID-el ellentétben)!
 
* Célja az adatok tárolása, naplózása és helyreállítás lehetőségének biztosítása
 
Forrás: [[Backup]]
 
   
== Backup megoldások ==
+
Az <tt>rdiff-backup</tt> [[Backup#Backup_megold.C3.A1sok|differenciális mentést]] hajt végre, a hagyományostól kissé eltérő formában. A megszokott backup-rendszereknél lenne egy "régen" készült teljes mentésünk, valamint inkrementális mentéseink, amelyek az ehhez képesti különbséget, a legutóbbi teljes mentés óta történt változásokat tartalmazzák. Az <tt>rdiff-backup</tt>-nál ez nagyjából fordítva van: a legfrissebb mentés mindig teljes, és a korábbi mentések inkrementálisak. Az <tt>rdiff-backup</tt> olyan fájlokat tárol, amelyek segítségével az aktuális mentésből előállíthatóak korábbi állapotok. Így az aktuális mentés visszaállítása rendkívül gyors (lényegében egyetlen másolás), és minél korábbi állapotot szeretnénk visszaállítani, annál tovább fog tartani a dolog.
* Teljes mentés
+
* Inkrementális mentés
+
Az első mentés egy teljes mentés, ami hosszú ideig tart, de a differenciák ettől kezdve nagyjából azonos idő alatt készülnek el és általában jelentősen gyorsabban, mint a teljes mentés (ez persze attól is függ, milyen és mennyi változás történik két mentés között).
** Kumulatív mentés
+
** Differenciális mentés
+
== Előnyök ==
Forrás: [[Backup#Backup_megold.C3.A1sok]]
 
   
== Rdiff-backup ==
 
Az rdiff-backup differenciális mentést hajt végre, a hagyományostól kissé eltérő formában. Hagyományosan, egy "régen" készült teljes mentéshez képest lennének a különbségi mentések, ahol csak az előző különbséghez képesti változásokat tartalmazza a következő mentés. Jelen esetben ez kicsit máshogy történik, mert a teljes mentés, mindig egy
 
tükrözése az aktuális állapotnak, és a korábbi állapotok visszaállíthatósága az azokhoz képesti különbségek tárolásával biztosított. Ennek a megoldásnak az az előnye, hogy a legutolsó mentés nagyon gyorsan visszaállítható, gyakorlatilag egy visszamásolással. Minél régebbi mentést szeretnék visszaállítani, annál tovább fog tartani a különbségek összefűzése, így a backupból való visszaállítás. Az első mentés egy teljes mentés, ez hosszú ideig tart, de az differenciák ettől kezdve nagyjából azonos idő alatt készülnek el és jelentősen gyorsabban, mint a teljes mentés.
 
=== Előnyök ===
 
 
* A teljes backup tükrözés formájában áll rendelkezésre, ezért nagyon gyorsan visszállítható belőle bármi.
 
* A teljes backup tükrözés formájában áll rendelkezésre, ezért nagyon gyorsan visszállítható belőle bármi.
* A különbségek mindig az előző mentéshez képest készülnek, így gyorsan megtörténik a biztonsági mentés
+
* A különbségek mindig az előző mentéshez képest készülnek, így gyorsan megtörténik a biztonsági mentés.
* Az különbségek tömörített formában vannak, így kis helyet foglalnak
+
* Az különbségek tömörített formában tárolódnak, így kevés helyet foglalnak.
* Rsync-re épül, így nincs egy teljesen új megoldás alapokról megvalósítva az összes gyermekbetegségével együtt
+
* Követi a Unix-filozófiát:
* Ssh-t használ a biztonságos kapcsolathoz, ami szintén nincs benne feleslegesen és hibásan újraimplementálva
+
** az rsync-re épül, nem írtak hozzá saját rsync-szerűséget.
* Már létezik natív windowsos kliens is hozzá
+
** Távoli gépekre ssh segítségével kapcsolódik, nem saját megoldással.
  +
* Natív windowsos kliens is létezik hozzá.
  +
  +
== Hátrányok ==
   
=== Hátrányok ===
 
 
* Nem folyamatos a backup, hanem eseti.
 
* Nem folyamatos a backup, hanem eseti.
 
* A teljes mentés tömörítés nélkül, tükrözés formájában van jelen, így sok helyet foglal.
 
* A teljes mentés tömörítés nélkül, tükrözés formájában van jelen, így sok helyet foglal.
* Nem tudja kódolt formában tárolni a biztonsági mentést (mint pl. duplicity)
+
* Nem tudja titkosítva tárolni a biztonsági mentést (pl. duplicity-vel ellentétben).
  +
  +
== Szakácskönyv ==
  +
  +
Ebben a fejezetben egy olyan konkrét rendszer beállítását mutatom be, amely egy vagy több távoli gép biztonsági mentését végzi el automatikusan, felügyelet nélkül, rendszeres időközönként. Inkrementális biztonsági mentést készít és a mentési folyamatot a backup szerverről indítjuk, így több gép biztonsági mentését is hatékony erőforráskihasználással végezhetjük.
  +
  +
=== A backup rendszer áttekintése ===
  +
[[Fájl:Attekintes1.png]]
  +
A "Backup server" az a szerverünk, ahol a biztonsági másolatokat szeretnénk tárolni, ill. ahonnan a biztonsági mentést indítjuk. Az rdiff-backup más módokon is képes működni, de ebben a leírásban azt a módszert mutatjuk be, amikor a backup szerver indítja a backup folyamatokat a backupolandó kliensek felé. Ennek az az előnye, hogy a backup folyamatok rövidebb ideig fognak tartani, mintha minden kliens össze-vissza próbálná feltölteni a saját filejait a backup szerverre. Így terhelési tüskék sem alakulnak ki sok kliens egyszerre csatlakozásakor, valamint priorizálhatjuk is a backup folyamatokat, pl. éjjelre a nappal nagyobb terhelésnek kitett szervereket, míg a kisebb terhelésű szervereknél nem annyira probléma, ha a backupolási folyamat belecsúszik a reggelbe.
  +
<BR><BR>
  +
[[Fájl:Attekintes2.png]]<BR>
  +
A cron gyűjtőscriptben helyezhetjük el az egyes backupscriptjeinket. Az egyes backup scriptekben pedig a backup kliensek backup folyamatait kell leírnunk. Milyen könytárakat, fileokat hova backupoljon a backup szerveren. Pl. Lehet, hogy külön helyen akarjuk tárolni a rendszerrel kapcsolatos fileokat és külön helyen a mail archívokat és megint külön helyen a webtartalmakat. Amikhez aztán, ha külön filerendszeren tároljuk őket külön-külön quota-t adhatunk meg (vagy megfelelő filerendszer esetén könyvtárakhoz rendelhetünk quota-t).<BR>
  +
A backup szerver a backup klienshez SSH-n keresztül csatlakozik és elindítja a backupolandó gépen az "sudo rdiff-backup --server" parancsot. Sudo-val indítja, hogy root jogosultsággal futhasson a program, így a rendszeren lévő fileokhoz root jogokkal férhessen hozzá. Az rdiff-backup --server módban fogadja a backup szerver utasításait arra vonatkozóan, hogy milyen fileokat kell megnéznie és azok különbségeit vagy a teljes filet átküldenie.
  +
A backup szerveren a backupoló folyamat user módban fut, és az rdiff-backup külön fileban tárolja a fileok dátum ill. jogosultság információit. Visszaállításkor természetesen, ahol a visszaállítás történik root jogokkal futnia szintén az rdiff-backupban. Valamint lehetőség van user mapping alkalmazására is visszaállításkor ha nem azon a rendszeren állítjuk vissza, ahol a backup készült. (És ha katasztrófa esetén szükség van a backupra akkor valószínű, hogy nem azon a rendszeren lesz visszaállítva)
  +
  +
=== A backup-szerver telepítése ===
   
= A backup szerver telepítése =
+
Ez a leírás alapértelmezett beállításokkal telepített Debian Lenny 5.0 rendszert feltételez úgy szerver-, mint kliensoldalon.
Ez a leírás alapértelmezett beállításokkal telepített Debian Lenny 5.0 rendszert feltételez, úgy szerver, mint kliens oldalon.
 
   
 
Csomagok telepítése:
 
Csomagok telepítése:
31. sor: 26. sor:
 
<pre>
 
<pre>
 
# apt-get update
 
# apt-get update
# apt-get install rdiff-backup sudo openssh-server fail2ban
+
# apt-get install rdiff-backup sudo openssh-server fail2ban \
# apt-get install hddtemp smartmontools munin-node munin-plugins-extra
+
hddtemp smartmontools munin-node munin-plugins-extra
 
</pre>
 
</pre>
   
; rdiff-backup
+
* rdiff-backup: maga a backup-program.
: A backup program.
+
* sudo: ahhoz szükséges, hogy az rdiff-backup-ot szerver-módban futtathassuk a célrendszeren. Mivel a backup-szerverről önmagáról is akarunk biztonsági másolatot készíteni, ezért ezen a rendszeren is szükség van erre.
; sudo
+
* openssh-server: azért kell, hogy a kliensek tudjanak kapcsolódni.
: Ahhoz szükséges, hogy az rdiff-backup-ot szerver módban futtathassuk a célrendszeren. Mivel a backup szerverről önmagáról is akarunk biztonsági másolatot készíteni, ezért ezen a rendszeren is szükség van erre.
+
* fail2ban: az ssh-s jelszópróbálgatókat tiltja ki (nem szükséges, csak ajánlott).
; openssh-server
+
* hddtemp, smartmontools, munin-node, munin-plugins-extra: monitorozáshoz (nem szükséges, csak ajánlott).
: A távoli bejelentkezéshez.
+
; fail2ban
+
=== SSH-szerver beállítása ===
: A bejelentkezési próbálkozások letiltására.
+
; hddtemp, smartmontools, munin-node, munin-plugins-extra
+
A <tt>/etc/ssh/sshd_config</tt>-ba írjuk bele az alábbiakat:
: A rendszer állapotának megfigyelésére.
 
   
=== SSH szerver beállítása ===
 
<pre>
 
# nano /etc/ssh/sshd_config
 
</pre>
 
 
<pre>
 
<pre>
 
PermitRootLogin no
 
PermitRootLogin no
55. sor: 46. sor:
 
</pre>
 
</pre>
   
;PermitRootLogin
+
* PermitRootLogin: letiltjuk a root bejelentkezését SSH-n keresztül (nem szükséges, csak ajánlott)
:Letiltjuk a root bejelentkezést SSH-n keresztül
+
* TCPKeepAlive: az SSH-t utasítjuk, hogy időnként küldjön keepalive-csomagot. Ez ahhoz kell, hogy hamarabb észrevegye, ha megszűnt a kapcsolat a klienssel. Nem szükséges, de ajánlott.
;TCPKeepAlive
+
* AllowUsers: Ezzel a direktívával adhatjuk meg, mely felhasználókat engedi bejelentkezni az sshd. Egyáltalán nem kötelező megadni, de ha beállítjuk, állítsuk be úgy, hogy a saját, a gép távmenedzsmentjére használt felhasználónk és a backupokkal kapcsolatos felhasználó is be tudjon lépni.
:Megbízhatóbban felismerjük a TCP kapcsolat hibáját
 
;AllowUsers
 
:Ezzel a direktívával korlátozzuk az SSH-n keresztül csatlakozó felhasználókat. Itt csak a saját felhasználónkat - amivel a szerver irányítását távolról végezzük - és a backupgép saját mentésének felhasználóját engedélyezzük!
 
   
=== iptables alapkonfig ===
+
=== Tűzfalszabályok ===
<pre>
 
# nano /etc/init.d/iptablesbuild
 
</pre>
 
<pre>
 
#!/bin/bash
 
   
# SETUP DEFAULT POLICIES
+
Értelemszerűen gondoskodni kell arról, hogy a mentendő kliensek tudjanak a szerver SSH-portjához kapcsolódni.
iptables -P INPUT DROP
 
iptables -P FORWARD DROP
 
iptables -P OUTPUT DROP
 
iptables -t nat -P PREROUTING ACCEPT
 
iptables -t nat -P POSTROUTING ACCEPT
 
iptables -t nat -P OUTPUT ACCEPT
 
iptables -t mangle -P INPUT ACCEPT
 
iptables -t mangle -P PREROUTING ACCEPT
 
iptables -t mangle -P FORWARD ACCEPT
 
iptables -t mangle -P POSTROUTING ACCEPT
 
iptables -t mangle -P OUTPUT ACCEPT
 
   
# FLUSH TABLES
+
=== Egy gép felvétele a backupolandó kliensek közé ===
iptables -F
 
iptables -X
 
iptables -t nat -F
 
iptables -t nat -X
 
iptables -t mangle -F
 
iptables -t mangle -X
 
   
# ALLOW LOOPBACK INTERFACE
+
Felhasználó felvétele: azért veszünk fel egyedi felhasználót, mert ennek a usernek a nevében fog futni majd az rdiff-backup a backup szerveren. Sima userként fut, jogosultságai korlátozottak és ennek a usernek lehet quota-ja is. Így az egyik backup nem eszi el a másik elől a helyet. A dátumot, jogosultságokat, stb. az rdiff-backup saját maga elintézi, tárolja külön.
iptables -I INPUT -i lo -j ACCEPT
+
A quota beállításokat az olvasóra bízom.
iptables -I OUTPUT -o lo -j ACCEPT
 
   
# ALLOW SSH
+
Tehát vegyük fel az új felhasználót a backup szerveren:
iptables -I INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
+
<pre>
  +
# adduser --system --ingroup nogroup --disabled-password <szervernév>
  +
</pre>
   
# ALLOW OUTGOING CONNECTIONS
+
Állítsunk elő neki egy új RSA-kulcspárt:
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
iptables -I OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
 
   
# LOG TRIALS
 
iptables -I INPUT -m limit --limit 1/s -j LOG
 
 
# RESTART FAIL2BAN
 
/etc/init.d/fail2ban restart
 
</pre>
 
Létrehozzuk a symlinket az Init részére:
 
 
<pre>
 
<pre>
# ln -s /etc/init.d/iptablesbuild /etc/rc2.d/S20iptablesbuild
+
# sudo -H -u <szervernév> ssh-keygen -t rsa -b 4096
 
</pre>
 
</pre>
   
=== Egy gép felvétele a backupolandó kliensek közé ===
+
Az új felhasználó <tt>~/.ssh/config</tt> fájljába írjuk bele a következőket:
Felhasználó felvétele:
 
<pre>
 
# adduser --gid 65534 --disabled-password <szervernév>
 
</pre>
 
RSA kulcspár generálása (4096 bites, RSA kulcspár):
 
<pre>
 
# su <szervernév>
 
$ cd ~
 
$ ssh-keygen -t rsa -b 4096
 
</pre>
 
   
Backup felhasználó profiljának szerkesztése
 
<pre>
 
nano /home/<szervernév>/.ssh/config
 
</pre>
 
 
<pre>
 
<pre>
 
host <szervernév>-backup
 
host <szervernév>-backup
 
hostname <szerverelérés, domain vagy IP>
 
hostname <szerverelérés, domain vagy IP>
 
user lhbackup
 
user lhbackup
identityfile /home/<szervernév>/.ssh/id_rsa
 
 
compression yes
 
compression yes
cipher blowfish
 
 
protocol 2
 
protocol 2
 
port 22
 
port 22
 
</pre>
 
</pre>
; hostname
 
: Ezzel a beállítással adhatjuk meg a távoli szerver elérhetőségét. Amivel megcímezhetjük.
 
; user
 
: A távoli szerveren lévő backup felhasználó neve. Lásd: A kliens telepítése
 
; compression
 
: Ezt a helyi gép backup beállításánál kikapcsolhatjuk. Hálózaton keresztül hasznos lehet.
 
   
=== Backup scriptek ===
+
A beállítások jelentését l. pl. az ssh_config(5)-ban; de talán egyértelműek is.
A backup scriptek az rdiff-backup paraméterezésének megfelelően egyszerűen elkészíthetőek. Ezeket aztán cronból futtathatjuk.
+
==== Példa a backup scriptekre ====
+
=== Backup-scriptek ===
  +
  +
A backup-scriptek az rdiff-backup paraméterezésének megfelelően egyszerűen elkészíthetőek. Ezeket aztán cronból futtathatjuk backup szerveren. Az rdiff-backup használatát legegyszerűbben példákon keresztül lehet jól megértetni és szemléltetni amihez segítség a következő link: [http://rdiff-backup.nongnu.org/examples.html Rdiff-backup Examples (angol)].
  +
A [[BackupNinja]] szócikkben is találhatunk példákat.
  +
  +
==== Példák ====
 
gep01:
 
gep01:
 
<pre>
 
<pre>
146. sor: 118. sor:
 
date
 
date
 
</pre>
 
</pre>
A gyűjtőscript használata azért célszerű, mert így a gépeket sorban menthetjük, folyamatosan és egyenletesen van terhelve a backup szerver.
+
A gyűjtőscript használata azért célszerű, mert így a gépeket sorban menthetjük, folyamatosan és egyenletesen van terhelve a backup-szerver.
A date és time parancsok segítségével láthatjuk az egyes backupok kezdési és befejezési idejét, valamint, hogy mennyi ideig tartott a procedúra.
+
A date és time parancsok segítségével láthatjuk az egyes backupok kezdési és befejezési idejét, valamint, hogy mennyi ideig tartott a procedúra. Természetesen ha a fenti példa alapján valósítjuk meg a scripteket, akkor számítanunk kell arra, hogy a cron naponta leveleket fog küldeni nekünk a backupolási folyamat eredményéről. Ha ez nem célunk, akkor minden mehet a /dev/null-ba. Figyeljünk arra, hogy a backup folyamat be tudjon fejeződni a rendelkezésre álló idő alatt. Tehát mielőtt újraindulna cron-ból a script. Ha nem fejeződik be, akkor átlapolódások jöhetnek létre, aminek nem látható következményei lesznek. Valószínűleg az rdiff-backup nem fog új backup folyamatot kezdeni a célkönyvtárban, mert felismeri, hogy már fut egy másik rdiff-backup azon a könyvtáron, de pl. a kitörölheti a már futó rdiff-backup alól a régi fileokat a "--force" opció miatt, aminek valószínűleg backup sérülés lesz az eredménye. Ha ezt nem akarjuk, akkor ne használjuk a --force opciót, aminek a következtében viszont betelhet a winchester ha olyat akarunk törölni, amit az rdiff-backup valamiért még megtartana.
   
= A kliensek telepítése =
+
== A kliensek telepítése ==
Ez a leírás alapértelmezett beállításokkal telepített Debian Lenny 5.0 rendszert feltételez, úgy szerver, mint kliens oldalon.
 
   
 
Csomagok telepítése:
 
Csomagok telepítése:
158. sor: 130. sor:
 
</pre>
 
</pre>
   
Backup felhasználó felvétele:
+
Itt létrehozunk egy backup felhasználót (lhbackup), amelynek a nevében a Backup Server majd be tud ssh-zni a mentendő gépre, és amely sudoval rootként tudja futtatni az 'rdiff-backup --server' parancsot:
 
<pre>
 
<pre>
# adduser --gid 65534 --disabled-password lhbackup
+
# adduser --ingroup nogroup --disabled-password lhbackup
 
# chmod 0700 /home/lhbackup
 
# chmod 0700 /home/lhbackup
 
</pre>
 
</pre>
Ha a backupoldandó gépen van AllowUsers direktíva használva az openssh-server beállításánál, akkor ott fel kell tüntetni az lhbackup felhasználót. Ha más módon korlátozva van a felhasználók bejelentkezése, akkor ott engedélyezni kell az SSH logint ennek a felhasználónak.
 
   
=== Sudo beállítása ===
+
=== A sudo beállítása ===
  +
 
<pre>
 
<pre>
nano /etc/sudoers
+
lhbackup ALL=(ALL) NOPASSWD: /usr/bin/rdiff-backup --server
</pre>
 
<pre>
 
lhbackup ALL=NOPASSWD:/usr/bin/rdiff-backup --server
 
 
</pre>
 
</pre>
   
 
=== További beállítások ===
 
=== További beállítások ===
A backup szerveren elkészített kulcspár nyilvános kulcsát át kell hozni a backupolandó szerverre. Ez a backup szerveren a jelenlegi leírás szerint a <pre>/home/<szervernév>/.ssh/id_rsa.pub</pre> helyen és néven található.
 
Az áthozott nyilvános kulcsot a backupolandó kliensen a <pre>/home/lhbackup/.ssh/authorized_keys2</pre> fileba kell helyezni. Ennek a filenak lhbackup tulajdonában kell lennie.
 
   
Ez után a filet a következő módon kell szerkeszteni:
+
Biztosítanunk kell, hogy az lhbackup user be tudjon lépni a mentendő gépre ssh-val, jelszó megadása nélkül; de ez még kevés. Az lhbackup user .ssh/authorized_keys fájljában a írjuk elő, hogy a backupszerver IP-jéről belépve csak az rdiff-backupot futtathatjuk:
  +
 
<pre>
 
<pre>
# nano /home/lhbackup/.ssh/authorized_keys2
+
command="sudo /usr/bin/rdiff-backup --server",from="<BACKUPSZERVER IPCIME>" <PUBLIKUS RSA-KULCS>
 
</pre>
 
</pre>
<pre>
 
command="sudo /usr/bin/rdiff-backup --server",from="<BACKUPSZERVER IPCIME>" <RSA PUBLIKUS KULCS>
 
</pre>
 
 
Ezzel engedélyezzük a backup szervert, hogy csatlakozzon a klienshez és futtassa a "sudo /usr/bin/rdiff-backup --server" parancsot.
 

A lap jelenlegi, 2010. január 18., 03:23-kori változata

Írta: Andocsi László, 2009. december.

Ez a szócikk az rdiff-backup nevű backup-megoldást mutatja be. Javaslom, hogy mielőtt elolvasod, nézd meg a Backup szócikket is, mert néhány ott leírt fogalmat itt csak használni fogok.

Az rdiff-backup differenciális mentést hajt végre, a hagyományostól kissé eltérő formában. A megszokott backup-rendszereknél lenne egy "régen" készült teljes mentésünk, valamint inkrementális mentéseink, amelyek az ehhez képesti különbséget, a legutóbbi teljes mentés óta történt változásokat tartalmazzák. Az rdiff-backup-nál ez nagyjából fordítva van: a legfrissebb mentés mindig teljes, és a korábbi mentések inkrementálisak. Az rdiff-backup olyan fájlokat tárol, amelyek segítségével az aktuális mentésből előállíthatóak korábbi állapotok. Így az aktuális mentés visszaállítása rendkívül gyors (lényegében egyetlen másolás), és minél korábbi állapotot szeretnénk visszaállítani, annál tovább fog tartani a dolog.

Az első mentés egy teljes mentés, ami hosszú ideig tart, de a differenciák ettől kezdve nagyjából azonos idő alatt készülnek el és általában jelentősen gyorsabban, mint a teljes mentés (ez persze attól is függ, milyen és mennyi változás történik két mentés között).

Tartalomjegyzék

[szerkesztés] 1 Előnyök

  • A teljes backup tükrözés formájában áll rendelkezésre, ezért nagyon gyorsan visszállítható belőle bármi.
  • A különbségek mindig az előző mentéshez képest készülnek, így gyorsan megtörténik a biztonsági mentés.
  • Az különbségek tömörített formában tárolódnak, így kevés helyet foglalnak.
  • Követi a Unix-filozófiát:
    • az rsync-re épül, nem írtak hozzá saját rsync-szerűséget.
    • Távoli gépekre ssh segítségével kapcsolódik, nem saját megoldással.
  • Natív windowsos kliens is létezik hozzá.

[szerkesztés] 2 Hátrányok

  • Nem folyamatos a backup, hanem eseti.
  • A teljes mentés tömörítés nélkül, tükrözés formájában van jelen, így sok helyet foglal.
  • Nem tudja titkosítva tárolni a biztonsági mentést (pl. duplicity-vel ellentétben).

[szerkesztés] 3 Szakácskönyv

Ebben a fejezetben egy olyan konkrét rendszer beállítását mutatom be, amely egy vagy több távoli gép biztonsági mentését végzi el automatikusan, felügyelet nélkül, rendszeres időközönként. Inkrementális biztonsági mentést készít és a mentési folyamatot a backup szerverről indítjuk, így több gép biztonsági mentését is hatékony erőforráskihasználással végezhetjük.

[szerkesztés] 3.1 A backup rendszer áttekintése

Attekintes1.png A "Backup server" az a szerverünk, ahol a biztonsági másolatokat szeretnénk tárolni, ill. ahonnan a biztonsági mentést indítjuk. Az rdiff-backup más módokon is képes működni, de ebben a leírásban azt a módszert mutatjuk be, amikor a backup szerver indítja a backup folyamatokat a backupolandó kliensek felé. Ennek az az előnye, hogy a backup folyamatok rövidebb ideig fognak tartani, mintha minden kliens össze-vissza próbálná feltölteni a saját filejait a backup szerverre. Így terhelési tüskék sem alakulnak ki sok kliens egyszerre csatlakozásakor, valamint priorizálhatjuk is a backup folyamatokat, pl. éjjelre a nappal nagyobb terhelésnek kitett szervereket, míg a kisebb terhelésű szervereknél nem annyira probléma, ha a backupolási folyamat belecsúszik a reggelbe.

Attekintes2.png
A cron gyűjtőscriptben helyezhetjük el az egyes backupscriptjeinket. Az egyes backup scriptekben pedig a backup kliensek backup folyamatait kell leírnunk. Milyen könytárakat, fileokat hova backupoljon a backup szerveren. Pl. Lehet, hogy külön helyen akarjuk tárolni a rendszerrel kapcsolatos fileokat és külön helyen a mail archívokat és megint külön helyen a webtartalmakat. Amikhez aztán, ha külön filerendszeren tároljuk őket külön-külön quota-t adhatunk meg (vagy megfelelő filerendszer esetén könyvtárakhoz rendelhetünk quota-t).
A backup szerver a backup klienshez SSH-n keresztül csatlakozik és elindítja a backupolandó gépen az "sudo rdiff-backup --server" parancsot. Sudo-val indítja, hogy root jogosultsággal futhasson a program, így a rendszeren lévő fileokhoz root jogokkal férhessen hozzá. Az rdiff-backup --server módban fogadja a backup szerver utasításait arra vonatkozóan, hogy milyen fileokat kell megnéznie és azok különbségeit vagy a teljes filet átküldenie. A backup szerveren a backupoló folyamat user módban fut, és az rdiff-backup külön fileban tárolja a fileok dátum ill. jogosultság információit. Visszaállításkor természetesen, ahol a visszaállítás történik root jogokkal futnia szintén az rdiff-backupban. Valamint lehetőség van user mapping alkalmazására is visszaállításkor ha nem azon a rendszeren állítjuk vissza, ahol a backup készült. (És ha katasztrófa esetén szükség van a backupra akkor valószínű, hogy nem azon a rendszeren lesz visszaállítva)

[szerkesztés] 3.2 A backup-szerver telepítése

Ez a leírás alapértelmezett beállításokkal telepített Debian Lenny 5.0 rendszert feltételez úgy szerver-, mint kliensoldalon.

Csomagok telepítése:

# apt-get update
# apt-get install rdiff-backup sudo openssh-server fail2ban \
hddtemp smartmontools munin-node munin-plugins-extra
  • rdiff-backup: maga a backup-program.
  • sudo: ahhoz szükséges, hogy az rdiff-backup-ot szerver-módban futtathassuk a célrendszeren. Mivel a backup-szerverről önmagáról is akarunk biztonsági másolatot készíteni, ezért ezen a rendszeren is szükség van erre.
  • openssh-server: azért kell, hogy a kliensek tudjanak kapcsolódni.
  • fail2ban: az ssh-s jelszópróbálgatókat tiltja ki (nem szükséges, csak ajánlott).
  • hddtemp, smartmontools, munin-node, munin-plugins-extra: monitorozáshoz (nem szükséges, csak ajánlott).

[szerkesztés] 3.3 SSH-szerver beállítása

A /etc/ssh/sshd_config-ba írjuk bele az alábbiakat:

  PermitRootLogin no
  TCPKeepAlive yes
  AllowUsers <saját felhasználó> lhbackup
  • PermitRootLogin: letiltjuk a root bejelentkezését SSH-n keresztül (nem szükséges, csak ajánlott)
  • TCPKeepAlive: az SSH-t utasítjuk, hogy időnként küldjön keepalive-csomagot. Ez ahhoz kell, hogy hamarabb észrevegye, ha megszűnt a kapcsolat a klienssel. Nem szükséges, de ajánlott.
  • AllowUsers: Ezzel a direktívával adhatjuk meg, mely felhasználókat engedi bejelentkezni az sshd. Egyáltalán nem kötelező megadni, de ha beállítjuk, állítsuk be úgy, hogy a saját, a gép távmenedzsmentjére használt felhasználónk és a backupokkal kapcsolatos felhasználó is be tudjon lépni.

[szerkesztés] 3.4 Tűzfalszabályok

Értelemszerűen gondoskodni kell arról, hogy a mentendő kliensek tudjanak a szerver SSH-portjához kapcsolódni.

[szerkesztés] 3.5 Egy gép felvétele a backupolandó kliensek közé

Felhasználó felvétele: azért veszünk fel egyedi felhasználót, mert ennek a usernek a nevében fog futni majd az rdiff-backup a backup szerveren. Sima userként fut, jogosultságai korlátozottak és ennek a usernek lehet quota-ja is. Így az egyik backup nem eszi el a másik elől a helyet. A dátumot, jogosultságokat, stb. az rdiff-backup saját maga elintézi, tárolja külön. A quota beállításokat az olvasóra bízom.

Tehát vegyük fel az új felhasználót a backup szerveren:

# adduser --system --ingroup nogroup --disabled-password <szervernév>

Állítsunk elő neki egy új RSA-kulcspárt:

# sudo -H -u <szervernév> ssh-keygen -t rsa -b 4096

Az új felhasználó ~/.ssh/config fájljába írjuk bele a következőket:

  host <szervernév>-backup
     hostname <szerverelérés, domain vagy IP>
     user lhbackup
     compression yes
     protocol 2
     port 22

A beállítások jelentését l. pl. az ssh_config(5)-ban; de talán egyértelműek is.

[szerkesztés] 3.6 Backup-scriptek

A backup-scriptek az rdiff-backup paraméterezésének megfelelően egyszerűen elkészíthetőek. Ezeket aztán cronból futtathatjuk backup szerveren. Az rdiff-backup használatát legegyszerűbben példákon keresztül lehet jól megértetni és szemléltetni amihez segítség a következő link: Rdiff-backup Examples (angol). A BackupNinja szócikkben is találhatunk példákat.

[szerkesztés] 3.6.1 Példák

gep01:

#!/bin/bash

EXCLUDES="--exclude /dev --exclude /proc --exclude /tmp --exclude /sys"

echo "Removing increments older than 30 days..."
/bin/su <szervernév> -m -c "/usr/bin/rdiff-backup --force --remove-older-than 30D /home/<szervernév>/backup"

echo "Backing up <szervernév>..."
/bin/su <szervernév> -m -c "/usr/bin/rdiff-backup $EXCLUDES <szervernév>-backup::/ /home/<szervernév>/backup"

gep02:

#!/bin/bash

EXCLUDES="--exclude /dev --exclude /proc --exclude /tmp --exclude /sys --exclude /opt"

echo "Removing increments older than 30 days..."
/bin/su <szervernév2> -m -c "/usr/bin/rdiff-backup --force --remove-older-than 30D /home/<szervernév2>/backup"

echo "Backing up <szervernév2>..."
/bin/su <szervernév2> -m -c "/usr/bin/rdiff-backup $EXCLUDES <szervernév2>-backup::/ /home/<szervernév2>/backup"

Ezt követően a cronból egy gyűjtőscriptet használhatunk:

#!/bin/bash

date
time /root/gep01
date
time /root/gep02
date

A gyűjtőscript használata azért célszerű, mert így a gépeket sorban menthetjük, folyamatosan és egyenletesen van terhelve a backup-szerver. A date és time parancsok segítségével láthatjuk az egyes backupok kezdési és befejezési idejét, valamint, hogy mennyi ideig tartott a procedúra. Természetesen ha a fenti példa alapján valósítjuk meg a scripteket, akkor számítanunk kell arra, hogy a cron naponta leveleket fog küldeni nekünk a backupolási folyamat eredményéről. Ha ez nem célunk, akkor minden mehet a /dev/null-ba. Figyeljünk arra, hogy a backup folyamat be tudjon fejeződni a rendelkezésre álló idő alatt. Tehát mielőtt újraindulna cron-ból a script. Ha nem fejeződik be, akkor átlapolódások jöhetnek létre, aminek nem látható következményei lesznek. Valószínűleg az rdiff-backup nem fog új backup folyamatot kezdeni a célkönyvtárban, mert felismeri, hogy már fut egy másik rdiff-backup azon a könyvtáron, de pl. a kitörölheti a már futó rdiff-backup alól a régi fileokat a "--force" opció miatt, aminek valószínűleg backup sérülés lesz az eredménye. Ha ezt nem akarjuk, akkor ne használjuk a --force opciót, aminek a következtében viszont betelhet a winchester ha olyat akarunk törölni, amit az rdiff-backup valamiért még megtartana.

[szerkesztés] 4 A kliensek telepítése

Csomagok telepítése:

# apt-get update
# apt-get install rdiff-backup sudo openssh-server

Itt létrehozunk egy backup felhasználót (lhbackup), amelynek a nevében a Backup Server majd be tud ssh-zni a mentendő gépre, és amely sudoval rootként tudja futtatni az 'rdiff-backup --server' parancsot:

# adduser --ingroup nogroup --disabled-password lhbackup
# chmod 0700 /home/lhbackup

[szerkesztés] 4.1 A sudo beállítása

lhbackup ALL=(ALL) NOPASSWD: /usr/bin/rdiff-backup --server

[szerkesztés] 4.2 További beállítások

Biztosítanunk kell, hogy az lhbackup user be tudjon lépni a mentendő gépre ssh-val, jelszó megadása nélkül; de ez még kevés. Az lhbackup user .ssh/authorized_keys fájljában a írjuk elő, hogy a backupszerver IP-jéről belépve csak az rdiff-backupot futtathatjuk:

command="sudo /usr/bin/rdiff-backup --server",from="<BACKUPSZERVER IPCIME>" <PUBLIKUS RSA-KULCS>
Személyes eszközök