Instruktaż/Tutorial Backup plików przez sieć na QNAP - metoda rsync

[Nicodem]

Przykładowe zastosowanie:
Codziennie wykonuję backup moich dokumentów z laptopa na QNAPa. Rozważałem różne możliwości backupu. W sieci LAN to nie problem - można skopiować pliki ręcznie, użyć FTP lub np za pomocą jakiegoś ulubionego programu do backupu danych.
Podstawowym problemem jednak była wielkośc katalogu który kopiuję - zawiera on w tej chwili ponad 16tys plików, prawie 3Gb danych.
Nawet w sieci LAN wysyłanie takiej ilości plików trwa długo. Pomyślałem o programie zewnętrznym który zajmie się backupem. Ale po co płacic, skoro mamy narzędzie o nazwie rsync.

Jak to działa
Kopiowane są tylko pliki nowe oraz te które uległy zmianie. Jeśli jakiś plik skasowano na komputerze z którego robimy backup - zniknie on i na QNAPie. Takich ustawień używam w moim przypadku. Efekt jest rewelacyjny - zamiast kopiować załość lub pamiętać które pliki zmieniałem/dodałem uruchamiam rsync i po chwili wszystko na QNAPie jest idealną kopią mojego katalogu. Chcesz poczytać o rsync - zapraszam na http://rsync.samba.org

OK, fajnie. Tak działa rsync ale w czym był problem?
Rsync pięknie działa w sieci LAN ale ja chciałbym mieć możliwość backupu także przez Internet. Nie mogę otworzyć po prostu portu rsyncd do serwera bo jest to zbyt niebezpieczne. Pojawiła się także potrzeba robienia takich backupów przez innych użytkowników.
Urządzenia QNAP mają jedną dość irytującą wadę - bezpieczne logowanie po SSH może się odbyć tylko dla konta administratora. Trzeba więc było obejść tę niedogodność.

Instalujemy OpenSSH
Zakładam że mamy zainstalowane Optware. Zalecam instalację przez QPKG. Stosowne HOWTO jest na forum.
Instalujemy paczkę OpenSSH

ipkg install openssh

Instalacja trochę potrwa - zwłaszcza tworzenie kluczy.
Mamy już ssh które przyjmie każdego z użytkowników QNAP. Odpalamy SSH:

/opt/sbin/sshd -p XX

gdzie XX to nowy numer portu. Tę wersję SSH używam tylko do replikacji plików.
Teraz trzeba sprawdzić czy na QNAPie działa demon rsync

ps | grep rsyncd

Jeśli nie ma takiego procesu uruchamiamy demona w następujacy sposób:

rsyncd --daemon --sever-type=0

Konfiguracja klientów
Do replikacji na systemach z rodziny linux zazwyczaj nic nie trzeba instalować. Większość dystrybucji ma ssh, rsync od razu zainstalowane.
Ja używam do pracy systemy Windows i spod niego chcę wykonywać replikację plików.
Potrzebujemy paczki rsync działającej pod Windows: http://itefix.no/cwrsync/
Z linii poleceń uruchamiamy w katalogu gdzie zainstalował się rsync polecenie:

rsync.exe -v -rlt -z --delete --rsh="ssh -l nazwauzytkownika -p XX" --progress --stats --no-whole-file "/cygdrive/nazwadysku/sciezka/" "nazwauzytkownika@adresIP_QNAPa:/share/Backup/sciezka/"

składnia jest następująca - nazwa użytkownika to nazwa usera QNAP na którego chcemy się zalogować, XX - port na którym nasłuchuje nasz OpenSSH na serwerze. Ścieżka zaczynająca się od cygdrive to ścieżka do katalogu który chcemy replikować. Ostatnia ścieżka - docelowe miejsce gdzie dane skopiowane mają wylądować.
W moim przypadku polecenie kopiujące z dysku D cały katalog Dokumenty do QNAPa do /share/Backup wygląda tak:

rsync.exe  -v -rlt -z --delete --rsh="ssh -l nazwauzytkownika -p XX" --progress --stats --no-whole-file "/cygdrive/D/Dokumenty/" "nazwausytkownika@adresserwera:/share/Backup/Dokumenty/"

To tyle. Odpalamy i gotowe. Pierwsza replikacja będzie trwać - przesyłane są wszystkie pliki. Kolejne replikacje to już mgnienie oka -przesyłamy tylko to co uległo zmianie. Oczywiście przy pierwszym uruchomieniu połączenia zapisane zostaną klucze SSH na komputerze klienta.

Ważne
Należy też pamiętać o przeforwardowaniu portu XX (daemon openssh) jeśli QNAP znajduje się za NATem. Inaczej się z nim nie połączymy.

Konfiguracja którą opisałem działa do pierwszego restartu. Należy więc zmodyfikować plik autostart.sh i zadbać o to aby demon OpenSSH startował razem z systemem. U mnie rsyncd startuje automatycznie - nie musiałem więc dodawać go do autostart. Odpowiedni HOWTO jest na forum.

Pozostaje też zabawa z użytkownikami - otworzyliśmy im wejście po SSH na serwer. Miło by było zatem aby zadbać o to by nie mogli za dużo gmerać w shellu.

 

[astonmartin]

Wielkie dzięki za to HOWTO, oczywiście pięknie działa

 

[Silas Mariusz]

good job

 

[Nicodem]

Wielkie dzięki za to HOWTO, oczywiście pięknie działa

Cieszy mnie to.
Właśnie napisałem krótką wersję po angielsku.
https://forum.qnap.com/viewtopic.php?f=22&t=8051

Idąc za ciosem:
- dodanie parametru -h do komendy rsync pokazuje ilości przesłanych danych w bardziej przystępny sposób (w kilo, mega i giga bajtach a nie w samych bajtach)
- całą operację można zautomatyzować dla użytkowników Windows. Niestety harmonogram zadań ma jedną przypadłość - jest tam trigger pozwalający na uruchomienie dowolnej komendy przy logowaniu użytkownika, ale nie przy jego wylogowywaniu lub zamykaniu komputera. Mogę się mylić ale nie widziałem takiej opcji. Z oczywistych względów synchronizacja powinna się wg mnie odbywać na koniec pracy . Dlatego zalecam użycie programu http://www.autohotkey.com/. Z tym małym narzędziem możemy szybko napisać skrypt który będzie uruchamiał synchronizację w dowolnym momencie. Np na zamknięcie jakiejś aplikacji, o dowolnej godzinie, kiedy pojawi się jakiś plik, gdy ktoś się wylogowuje itp itd. Wszystko zależy od intencji autora. Możliwości są praktycznie nieskończone.
- zamiana parametru -v na -vv lub -vvv wyrzuci nam na ekran więcej informacji o progresie całej operacji. Pokazuje to w fajny sposób jak działa rsync klient/serwer. Poznanie tego mechanizmu zachęca do eksperymentowania z innymi opcjami. W sumie nic nie stoi na przeszkodzie aby synchronizacja odbywała się w dwie strony. Teraz robimy kopię z klienta na serwer. Można robić pełną synchronizację.
Jak już wspomniałem - możliwośći jest mnóstwo. Zachęcam do zabawy i dzielenia się spostrzeżeniami

 

[astonmartin]

Mam problem z uprawnieniami do plików kopiowanych tą metodą. Przez ssh loguję się jako zwykły użytkownik, nie admin, nazwijmy go: user. Pliki się pięknie kopiują ale stają się własnością użytkownika admin z grupy administrators. Dlaczego tak jest ? Czy nie powinny być własnością użytkownika user skoro to on je tam umieścił ? Jak wrzucam tam pliki przez Sambę to właśnie tak jest. W panelu administracyjnym user ma ustawiony pełny dostęp.

Przeszkadza mi to ponieważ jeśli później podmontuje docelowy katalog w Windows jako user w ogóle nie widzę plików tylko puste katalogi. Dodatkowo komenda do zmiany właściciela jakoś nie chce działać.

chown -Rh user /share/HDA_DATA/katalog

zmienia właściciela tylko katalogu a podkatalogi i pliki pozostają nadal własnością admina. Co robię źle ?

//edycja

Korzystając z WinSCP udało mi się zmienić właściciela wraz z podkatalogami i plikami w nich. Problem jest niestety nadal, jeśli podepnę ten zasób przez sambę to nieważne czy zrobię to jako user czy jako admin - plików nie widać. Fizycznie pliki tam są bo zalogowany przez putty jako admin widzę je ale tylko w takim przypadku. Co z tym zrobić ?

 

[Nicodem]

Mam problem z uprawnieniami do plików kopiowanych tą metodą. Przez ssh loguję się jako zwykły użytkownik, nie admin, nazwijmy go: user. Pliki się pięknie kopiują ale stają się własnością użytkownika admin z grupy administrators. Dlaczego tak jest ? Czy nie powinny być własnością użytkownika user skoro to on je tam umieścił ? Jak wrzucam tam pliki przez Sambę to właśnie tak jest. W panelu administracyjnym user ma ustawiony pełny dostęp.

Przeszkadza mi to ponieważ jeśli później podmontuje docelowy katalog w Windows jako user w ogóle nie widzę plików tylko puste katalogi. Dodatkowo komenda do zmiany właściciela jakoś nie chce działać.

chown -Rh user /share/HDA_DATA/katalog

zmienia właściciela tylko katalogu a podkatalogi i pliki pozostają nadal własnością admina. Co robię źle ?

zarowno do SSH jak i do rsynca wchodzisz jako user? (-l user i potem user@adresip) ?
sprobuj moze opcji -a zamiast -rlt
moze to zadziala
jeszcze mozesz dodac:
zamiast -v zrob -vvv - to pozwoli na debuggowanie informacji
i dodaj -log-file=nazwapliku.txt - wyrzuci log do pliku
sprawdz tam czy nie ma dziwnych komunikatow odnosnie onwership plików
a ten katalog do ktorego robisz synchronizacje to ne byl przypadkiem zakladany przez admin'a?
zmien moze recznie wlasiciela glownego katalogu na user'a ktorego uzywasz

na dniach sprawdze co i jak i dodam pewnie do howto informacje jak zrobic tak aby nie trzeba bylo wpisywac hasla przy uzywaniu ssh (wymiana kluczy)
to ulatwi automatyzacje

 

[astonmartin]

Przepraszam za zamieszanie. To co napisałem w poprzednim poście to jakieś głupoty wynikające z mojej niewiedzy. Źle określiłem problem. Nie wynika on z metody kopiowania jak myślałem tylko z czegoś innego ale z czego nie wiem. Musiałem coś namieszać bo teraz przeprowadziłem gruntowne testy na dwóch komputerach i wszystko jest jak trzeba, tzn pliki się kopiują i są widoczne w podpiętym przez sambę zasobie. Problem polega na tym, że tylko te pliki które dodałem teraz a wszystko co skopiowałem wcześniej nie jest widoczne, tzn widoczne są tylko katalogi bez zawartości.

Jeśli teraz usunę jakiś plik z qnapa, uruchomię ponownie polecenie rsync na komuterze z windows to zostaje on ponownie skopiowany i jest widoczny z windows. Jest to niby jakieś rozwiązanie ale wymaga ponownego kopiowania a to proces dość długi. Chciałbym przywrócić "widoczność" tych plików bez ponownego przesyłania ich i nie wiem jak to zrobić. Zauważyłem, że pliki i katalogi które teraz dorzucam stają się własnością użytkownika smbuser i grupy everyone, jako admin wykonałem więc polecenie:

chown -Rh smbuser:everyone /share/HDA_DATA/nas

Teraz jak sprawdzam to przypisanie praw działa (wcześniej patrzyłem nie tam gdzie trzeba szolomiony: ). Tyle, że nic to nie zmienia jeśli chodzi o dostęp do plików, nadal z windows widzę tylko te nowo dodane.

 

[Nicodem]

sprawdz jakie masz prawa dostepu.
z tego co wiem to jest jakis bug i prawo wx w rezultacie daje pliki hidden pod Windows.
Zmień prawa np na rwxrw-rw- i powinno być OK.

Daj znać czy to coś pomogło.

 

[astonmartin]

wynik komendy ls -la w katalogu, który widzę z windows wraz z zawartością:

drwxrwx---    2 smbuser  everyone     4096 Mar  5  2008 ./
drwxrwx---   13 smbuser  everyone     4096 Sep 16 20:20 ../
-rwxrwx---    1 smbuser  everyone    25088 Jan  7  2005 HDAPROP.DLL*

i to samo ale w katalogu, który w windows jest widoczny ale bez plików wewnątrz:

drwxrwxrwt    2 smbuser  everyone     4096 Feb 14  2008 ./
drwxrwxrwt   12 smbuser  everyone     4096 Sep 16 16:15 ../
-rwxrwxrwx    1 smbuser  everyone2845816832 Oct 10  2007 pro-htote.iso*

i rzeczywiście zmiana praw dostępu załatwia sprawę, będąc w katalogu /share/HDA_DATA/ wykonałem:

chmod -R 770 nas

i wszystkie pliki są widoczne pod windows

Dzięki za rozwiązanie problemu.

Ale to faktycznie chyba jakiś błąd w systemie qnapa albo w sambie żeby pliki o pełnych uprawnieniach nie były widoczne

 

[Nicodem]

[ciach]

i rzeczywiście zmiana praw dostępu załatwia sprawę, będąc w katalogu /share/HDA_DATA/ wykonałem:

chmod -R 770 nas

i wszystkie pliki są widoczne pod windows

Dzięki za rozwiązanie problemu.

Ale to faktycznie chyba jakiś błąd w systemie qnapa albo w sambie żeby pliki o pełnych uprawnieniach nie były widoczne

Najprawdopodobniej samba. Jest jeszcze jedna opcja w rsync zapewniajaca wspolprace miedzy systemami. Nie pamietam teraz parametru. Przejrzyj man rsync

 

[weze]

mam to samo, porpostu rsyncd działa jako administrator i wgrane poprzez RSYNC pliki na QNAP'a stają sie własnością administratora.
Mój qnap ma w głebokim poważaniu uprawnienia, i nie ważne czy podam usera podczas RSYNC czy nie to i tak mam dostęp absloutnie wszędzie (mam grupy i po SMB/CIF jest OK)

 

[bba]

Jak to się będzie sprawdzało na 209 PRO i użytkownikami pobranymi z AD. I czy jest opcja dodania skryptu przy wylogowaniu w GP(WIN SRV 2008). Narazie robię to tak że użyszkodnicy się synchronizują na serwer a potem net backrepicator wysyła na Qnapa zawartość ich katalogów. Ale zaraz może mi się miejsce na serwerze skończyć.