Mentés (backup)

A mentés a nagyon fontos gyakorlati rendszergazdai teendő. Az informatika egyik alaptétele a következő: ha egy adat csak egy helyen van meg, az nincsen (!).

Ezért fontos mentési stratégiát kialakítani egy szerver, de akár a desktop gépünk, illetve hordozható eszközünk esetében is! Tiszteljük meg annyira saját magunkat, hogy saját munkáinkat, adatainkat, leveleinket, kapcsolatainkat, etc. legalább lementjük egy fizikailag különböző helyre időközönként! Erre szolgál egyébként a felhő is. Azonban nem minden esetben kifizetődő a használata! Egyébként pl. az ownCloud felhőt mi is telepíthetjük. Lehet saját felhőnk is!

https://owncloud.org/

Nézzük azonban a klasszikus backup-ot, mondjuk egy kódolt hálózatit.

A szeptember 16-ai írásomban az SSH-ról leírtam a publikus kulccsal hitelesített jelszó nélküli kapcsolatot. Ez tökéletes alap egy hálózati mentéshez. Hirtelen két stratégia is eszembe jut.

  1. A távoli szerveren fut egy ún. cron job, a felhasználói crontab-ban – ez egy ütemezett feladatot jelent – mondjuk naponta. Egy script. ami ún. .tar.gz vagy .tgz tömörített állományt (archívumot) hoz létre – ez a Linux/UNIX rendszerek saját ZIP megoldása – a menteni kívánt könyvtárból, természetesen rekurzívan. Futhat pl. hajnai 3-kor. Hajnali fél négykor pedig a helyi gépünkön, ahova mentünk, lefut egy másik script, ami scp-vel, jelszó nélküli átvitelben átmásolja, “letölti” a tömörített állományt. 🙂
  2. A második megoldásban az “ssh” parancs segítségével a távoli gépen – amiről a mentést készítjük – egy scriptet futtatunk, amiben tömörítjük a menteni kívánt könyvtárat a “tar czvf <archívum_időbélyeg.tgz> <könyvtár>” paranccsal vagy a tar és a gzip parancsok kombinációjával (tar cvo <könyvtár> | gzip – > <archívum_időbélyeg.tar.gz>), ezt követően pedig scp-vel átmásoljuk a helyi gépünkre. Ezt elég lesz helyileg ütemeznünk, de akár kézzel is indíthatjuk. 🙂

https://www.shellhacks.com/ssh-execute-remote-command-script-linux/

Látható, hogy nem ördöngősség a mentés. Jóllehet azért nagyon nagy mennyiségű adat mentésénél már több eszközre van szükségünk, mint egy-két Linux parancs. 🙂

Meg kell említsem még a bzip2-t, mint egy újabb, és hatékonyabb tömörítő algoritmust használó tömörítő programcsomagot (https://www.sourceware.org/bzip2/). Általában igaz, hogy a tar archivál, a gzip és a bzip2 pedig tömörítenek. Ma már a bzip2 is alapból telepítve van egy Linux-on, sőt tar-ból is elérhető a “-j, –bzip2” kapcsolóval. Az alábbi linken található még néhány hasznos információ az archiválásról.

https://www.thomas-krenn.com/en/wiki/Archive_under_Linux_(tar,_gz,_bz2,_zip)

Reklámok

A log-olás (logging), naplózás alapjai

Linux rendszerünkben – pláne ha szerver – sokféle esmény történik. Ezek nyomot is hagynak – már ha jól van minden beállítva -, alapvető helyük az ún. syslog (rendszer napló), helye a könyvtárstruktúrában “/var/log/syslog“.

Beszélnünk kell még egy alapvető dologról. Minden folyamatnak van egy bemenete (STDIN, száma 0) és két kimenete: a standard kimenet (STDOUT, száma 1) és a standard hibakimenet (STDERR, száma 2).

Nézzük meg, hogyan lehet egy folyamat mindkét kimenetét “log-olni”! 🙂

root@gergo1:~# ls -lR / &> logfile

Ez aztán létrehoz nálam egy cirka 70 MByte-os logfile-t. Benne a “sima” kimenet, és a hibák is. Lássunk erre példát!

root@gergo1:~# grep "proc" logfile | less
..
/proc/11/fd:
/proc/11/fdinfo:
/proc/11/map_files:
/proc/11/net:
/proc/11/net/dev_snmp6:
/proc/11/net/netfilter:
/proc/11/net/stat:
/proc/11/ns:
/proc/11/task:
/proc/11/task/11:
ls: cannot read symbolic link '/proc/11/task/11/exe': No such file or directory
..

Látható a kimenet, és egy hiba is. Az előbbivel ekvivalens a “klasszikus” formájú parancs.

root@gergo1:~# ls -lR / > logfile.1 2>&1

Látható, hogy az STDERR “file” bele van “irányítva” az STDOUT “file”-ba, és mindkettő a “logfile.1”-be.

Vigyázat! A szimpla “kacsacsőr“, a “>” jel lenullázza a kimeneti file-t. Ha csak hozzáírni akarunk egy logfile-hoz, akkor a “dupla kacsacsőrt” kell használnuk: “>>“. Ez a “hozzáfűzés” (append).

Természetesen minden szerverfolyamatnak van log-ja, így pl. a webszerver logfile-jait a “/var/log/apache2” könyvtár alatt találjuk meg.

root@gergo1:~# l /var/log/apache2/
total 116
-rw-r—– 1 root adm 0 Sep 24 00:00 access.log
-rw-r—– 1 root adm 148 Sep 23 22:49 access.log.1
..
-rw-r—– 1 root adm 309 Sep 22 13:10 access.log.2.gz
..
-rw-r—– 1 root adm 239 Sep 24 00:00 error.log
-rw-r—– 1 root adm 869 Sep 24 00:00 error.log.1
..
-rw-r—– 1 root adm 337 Sep 23 00:46 error.log.2.gz
-rw-r—– 1 root adm 337 Sep 22 00:00 error.log.3.gz
..

Látható, hogy a régebbi logok egy számot kapnak, majd tömörítve vannak gzip-pel (a .gz kiterjesztés erre utal), naponta új logfile készül. Van “hozzáférési napló” (access log), illetve “hibanapló” (error log).

Egy logfile-t a “tail -f” paranccsal tudunk úgy megnyitni, hogy folyton lássuk az újabb sorokat, lévén ez is szövegfile. Semmi extra! 🙂

És végezetül szeretném megjegyezni, hogy leht log-olni akár egy terminálra is. Régebben a “/dev/tty12“-re, az utolsó terminálra írtam az összefoglaló logot, hogy egy egyszerű terminál-váltással (ctrl+alt+f12) azonnal láthassam, hol van valami “hiba” a szerveren. 🙂