Backup távoli gépre, jogokkal

UNIX haladó

Sziasztok,

Van egy éles gép meg egy backup gép. Mindkettőn FreeBSD fut. Külön szerver teremben vannak. Az lenne a feladat, hogy a backup gépet max. 1-2 nap késéssel olyan formában tartsam, hogy szükség esetén gyorsan át lehessen oda tenni az éles szolgáltatást.

A gépen NAGYON sok adat van. Főleg clipart képek, termékek képei, és sok felhasználó nálunk tárolt fotói és videói. Több millió állomány, sok 10 ezer könyvtárban. De vannak más adatok is (napló fileok, adatbázisok stb.) Állományok száma szerint nézve, az állományok nagy része sosem változik. Egyszer le lett töltve és ott van. Inkább az a jellemző hogy új állományok jönnek létre. Van egy kisebb részük ami folyton változik. Namost az van, hogy a backup gépen és az éles gépen is ugyan olyan user id-vel ugyan azok a felhasználók vannak fölvéve. Az összes szolgáltatás (pl. apache) úgy van beállítva, hogy minimális változtatással a backup szerverből éles szervert lehessen varázsolni. Ez fontos, mert ha az éles szerver tönkremegy, akkor nagyon gyorsan át kell tudnunk állni a backup gépre.

Csak annyi a bökkenő, hogy a működéshez szükséges állományok több különböző user tulajdonát képezik. Valahogy úgy kellene szinkronizálni ezeket a könyvtárakat a gépek között, hogy a jogosultságok (és a file tulajdonosok!) megmaradjanak.

Korábban erre cpdup-ot használam, ami elég gyors volt. De ez csak gépen belüli mentésre működött. Most hogy a backup egy másik gépen van, eszembe jutott az rsync. Biztonságos is kellene hogy legyen, tehát lehetne rsync + SSH. Viszont ehhez az kellene, hogy az rsync root jogokkal jelentkezzen be a backup gépre. Ehhez engedélyezni kellene a root ssh logint, amitől azért eléggé tartok.

Szóval a kérdések:

* Mekkora biztonsági kockázat lenne rsync+SSH úgy, hogy a backup gépre root-ként jelentkezik be? (Ez elég hülye kérdés...)
* Mennyire lesz hatékony az rsync? Ha van 20 millió kis file, és a nagy részükben nincsen változás, akkor mennyi idő alatt képes szinkronizálni 100MBit kapcsolaton, és mekkora forgalmat generál? Tudom, próbáljam ki. De akkor is, nagyon érdekelne hogy ez így elméletben mennyire működőképes.
* Talán az állományok tárolásának módját megváltoztatva nagyobb hatékonyságot tudnék elérni. Például, valamilyen distributed filesystem ami alapból két gépre ír, de csak egy gépről olvas. Így nem kellene végigolvasni az összes könyvtárat, hanem csak azokat szinkronizálná amik ténylegesen írva lettek. Ennek további előnye lenne, hogy nagyon up-to-date mentésem lenne az éles szerverről (egy két óra eltérés max.) Valaki csinált már ilyet? Érdemes ezt két gép esetén is megvalósítani? (Egyelőre nem lesz 10 gépem.) Ha érdemes, akkor milyen csomagot tegyek föl, ami erre való?

Köszi,

Laci

  • 5878 megtekintés

( Fisher v | 2012. 09. 17., h – 12:17 )

20M file sokáig(*) fog tartani, és a disk io fogja nyomni a gépet.

Az rsync + ssh + root biztonsága X. Az,hogy neked ez elegendő-e, az más kérdés. Számos lehetőség van, divat pl. más portra eldugni az ssh-t (muhaha), de a tűzfalban is lehet limitálni, hogy egyáltalán az SSH-t honnét engedi be.

Ha nincs sok írásod, és stabil a net, akkor el lehet gondolkozni a drbd-n, azt be lehet úgy is állítani, hogy ne ragaszkodjon a távoli szerver visszajelzéséhez, hogy ott is diskre került az adat.

*) mi az hogy sokáig? Ez marha sok dologtól függ.

( aegitalos | 2012. 09. 17., h – 12:36 )

# Ehhez engedélyezni kellene a root ssh logint, amitől azért eléggé tartok.

A /root/.ssh/authorized_keys-ben korlátozni tudod, hogy
melyik IP címről (éles gép) és milyen parancsot lehessen csak végrehajtani.
Ez nagyban csökkenti a kockázatot.

A command opcióban megadhatsz egy szkriptet, ami ilyesmi:


#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
*\&*)
echo "Rejected"
;;
*\(*)
echo "Rejected"
;;
*\{*)
echo "Rejected"
;;
*\;*)
echo "Rejected"
;;
*\<*)
echo "Rejected"
;;
*\`*)
echo "Rejected"
;;
rsync\ --server*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Rejected"
;;
esac

( maszili | 2012. 09. 17., h – 12:53 )

Én a következőt javasolnám:

A mentendő gépen indítsd szervízként (873-as port) az rsync-et majd konfiguráld úgy, hogy csak read-only és csak a backup szerver IP címéről fogadjon kapcsolatot User/Pass azonosítás (ami nem kell, hogy root legyen) után.

(1) a mentendő gépen logikai adatbázis dump készítése a távoli gépre mentés előtt
(2) a backup gép kapcsolódjon a mentendő szerverhez és hozza szinkronba az előző mentést a jelenlegi szerver állapottal. Esetleg hardlinkes kapcsolókkal több állapotot is megtarthatsz csak a változások méretét használva.

Így egy-egy mentés rövid idő alatt lemegy és a teljes fájlrendszeredről van komplett másoladod, beleértve az adatbázis logikai mentéseket is.

--
maszili

(1) a mentendő gépen logikai adatbázis dump készítése a távoli gépre mentés előtt

Ezt nem tudom hogy gondoltad. Sok 10 ezer könyvtárban van 20M+ állomány. Az állományok 99%-a soha nem változik. De a változások szét vannak szórva a könyvtárak között. Hogy lehet erről "logikai adatbázis dump"-ot csinálni?

Végülis az adatbázis dump mentése nem probléma. Mert ott nincs probléma a jogosultságokkal. Ha át kell állni a backup szerverre, akkor úgyis kell egy db restore. A db dump közvetlenül nem használható föl éles környezetben. Erre egy akármilyen "backup" nevű, nulla jogokkal rendelkező user is használható.

A problémám az az összes többi kis millió állománnyal volt, amik 100 user neve alatt vannak. Mert jogosultságokkal együtt azt csak root jogokkal lehet sync-elni.

De ezekkel együtt:

PermitRootLogin forced-commands-only without-password

az rsync+SSH elég biztonságosnak tűnik.

Köszönöm a segítséget!

( andrej_ v | 2012. 09. 17., h – 13:56 )

Én két utat látok, illetve hármat.

1) SSH-n keresztül rsync minden éjjel és persze SQL-ről dump előtte, amit exclude-olhatsz is. Az SSH-t AllowUsers X@ipcim formában konkrét IP-re tudod kötni és egyébként nem árt az egyedi port alkalmazása sem, de az egyedi porttól biztonságos nem lesz. Egyszerűen kulcsos auth-al beereszted a juzert és kész.

2) A lentebb írt rsyncd-s opció, de ott megnézném, hogy tudja-e tömöríteni a kapcsolatot az rsync és hogy mennyire cleartext. Egy AES-128-as OpenVPN tunnel hasznos lehet, mert az tömöríti is a forgalmat ebben az esetben.

3) Ha esetleg ZFS-t használsz, akkor van zfs send és zfs receive opció, amivel snapshotokat lehet akár másik gépre is átküldeni.

A forgalmad nem lesz veszélyesen magas, úgyis a havi átlagot nézik a szolgáltatók. Amire figyelni kell, hogy ha ennyire sokminden van, akkor ne érjenek egymásba a mentések, mert az roppant kellemetlen lehet.

( nagylzs v | 2012. 09. 28., p – 12:03 )

Beállítottam az rsync-et úgy ahogy leírtátok. Megfelelő a sebessége is. Viszont néha IDLE állapotba kerül a processz és úgy marad. Így a mentések nem valami megbízhatóak. Van egy shell script ami az rsync-et meghívja több könyvtárra. (Van aminek átad --delete kapcsolót is, van aminek nem.) Ha elindítom a script-et akkor valami ilyesmik futnak:

# ps ax | grep rsync
115 1 S+ 0:00.01 tail -f rsync_data_images.log
99836 1 S 0:00.01 /bin/sh ./rsync_with_backup.sh 2 rsync_with_backup.log
99837 1 D 0:23.77 rsync -avz --log-file rsync_data_images.log /data/images root@backup:/data
99838 1 S 0:05.19 ssh -l root backup rsync --server -vlogDtprze.iLf . /data
2371 5 DL+ 0:00.00 grep rsync

Namost az a gond hogy az az rsync processz ami a logfile-t írja az egyszercsak "megáll". Mintha örökké várakozna valamire. Nincsen hibaüzenet.

Amikor épp nincs kedve lefagyni, akkor a log állomány valahogy így ér véget:

2012/09/28 05:46:29 [99837]
2012/09/28 05:46:58 [99837] sent 43587897 bytes received 6312 bytes 174726.29 bytes/sec
2012/09/28 05:46:58 [99837] total size is 106395200103 speedup is 2440.58

Viszont ha épp úgy van kedve hogy nem megy tovább akkor ilyesmit látok:

2012/09/28 05:52:52 [7642]
2012/09/28 05:52:52 [7642]
2012/09/28 05:52:52 [7642]
2012/09/28 05:52:52 [7642]
2012/09/28 05:52:52 [7642]
2012/09/28 05:52:52 [7642]
2012/09/28 05:52:52 [7642]
2012/09/28 05:52:52 [7642]
2012/09/28 05:52:52 [7642]
2012/09/28 05:52:52 [7642]

Itt a vége. Szóval nincs hibaüzenet. A processz az fut, a log állomány meg van nyitva írásra, de semmit nem ír bele. A hálózati kapcsolat hibáját kizárnám. De mégha ez is lenne a baj akkor is az rsync-nek valami hibával kellene leállni ahelyett hogy a semmire várna.

Namost ami még furcsább, hogy az rsync-et a script indítja el. Az rsync az IDLE, de közben a shell script elkezdi zabálni a CPU-t. Valahogy így:

gandalf@shopzeus# ps ax | grep rsync
7642 1 I 0:07.41 rsync -avz --log-file rsync_data_media.log /data/media root@backup:/data
7643 1 I 0:18.13 ssh -l root backup rsync --server -vlogDtprze.iLf . /data
11636 1 S+ 0:00.00 grep rsync
99836 1 R 3:20.26 /bin/sh ./rsync_with_backup.sh 2 rsync_with_backup.log

Itt 99836 script indította el 7642 rsync parancsot. Ennek ellenére az sh script az [R]unning, az rsync az meg [I]dle. A top-ban meg így néz ki a dolog:

CPU: 39.1% user, 0.0% nice, 9.6% system, 0.5% interrupt, 50.7% idle
Mem: 7791M Active, 5397M Inact, 3259M Wired, 1042M Cache, 2465M Buf, 25M Free
Swap: 12G Total, 7916K Used, 12G Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
99836 root 1 119 0 8340K 1640K CPU0 0 6:46 100.00% /bin/sh ./rsync_with_backup.sh 2 rsync_with_backup.log

Tehát a shell script 100% CPU-t zabál. Amit nem igazán értek, mert a shell scriptnek kb. semmit nem kellene csinálnia a várakozáson kívül. Érdekes módon ha küldök neki egy TERM szignált akkor szépen kilép. Szóval igazából nincs lefagyva, de fogalmam nincs mit csinál.

Majd biztos lesz valaki aki strace-t fog javasolni. De ennek nem sok értelme van. Egyrészt a shell script zabálja a CPU-t, és a bourne shell az nem hiszem hogy bugos. :-) Az rsync-re is tehetnék strace-t, de az egy elég durva napló lesz. Bár most nincs más ötletem.

Amúgy a shell script fagyós része az valahogy így néz ki:

#!/bin/sh

data_copy_only="images
incbackups
konyveles
log
media
pgbackups
product_list
settlement"

for i in $data_copy_only
do
echo "#================================================"
echo "# rsync -avz --log-file rsync_data_${i}.log /data/${i} root@backup:/data"
echo "#================================================"
`rsync -avz --log-file rsync_data_${i}.log /data/${i} root@backup:/data`
done

Nem egy bonyolult dolog, és halvány gőzöm nincs hogy ebből hogy csinál 100% CPU terhelést?

Valaki???