Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Kopia zapasowa — cóż to takiego? cz. II — backup w systemie Linux

Kopia zapasowa jest bardzo ważnym elementem dzisiejszej informatyki. Trwałość obecnych nośników danych jest dość wysoka, ale zawsze istnieje ryzyko awarii. Niedawno opublikowałem pierwszą część mojej serii o kopiach zapasowych. W pierwszym epizodzie skupialiśmy się głównie na macierzach dysków. Jakie zadanie mają macierze? Przypomnijmy - mają służyć do szybkiego wznowienia pracy po awarii sprzętowej jednego lub więcej nośników danych. W tym wpisie zajmiemy się naszym głównym celem - backupami plików, kopiami zapasowymi. Poznamy metody ich szybkiego i łatwego wykonywania. W tej części zajmiemy się systemem operacyjnym Linux. Dowiemy się też co nieco o kolejnych nośnikach przechowywania danych.

Gdzie mogę przechowywać kopie zapasowe?

W poprzednim epizodzie zajmowaliśmy się nośnikami optycznymi i dyskami twardymi - wszak to jedne ze starszych i bardziej popularnych mediów, na których możemy przechowywać dane. Warto także zwrócić uwagę na inną parę nośników. Jeden z rodzajów, usługą chmurową zwany, zdobył dość sporą popularność. „Chmura” jest zintegrowana zarówno z najnowszymi produktami ze stajni Redmond, jak i Mountain View. Drugi nośnik stanowi natomiast lokalną, stojącą w domu, całkowicie darmową wariację dysków sieciowych.

O czym mowa?

Onedrive, Dropbox, Google Drive, Mega - te popularnie zwane “chmury” są ostatnimi czasy niezwykle popularnym tematem. Możemy za darmo przechowywać w nich określoną ilość danych. Do tych plików, dzięki przechowywaniu ich na dyskach internetowych gigantów, mamy dostęp z każdego miejsca na świecie. Wierzymy, że nasze dane w usługach chmurowych są dobrze zabezpieczone. Wszak, podobno wszystkie docierające tam pliki są szyfrowane w locie i ludzie obsługujący ten system nawet jeśli by chcieli, to nie mogą ich odczytać. Microsoft dwa lata temu poinformował, że do swoich usług Onedrive oraz Outlook wprowadza szyfrowanie TLS oraz mechanizm PFS, który ma utrudnić ewentualne odszyfrowanie danych przez napastnika, który dysponuje większą mocą obliczeniową. Na ile możemy wierzyć słowom prezesów wielkich firm z Redmond czy Mountain View? To już należy ocenić samemu.

Dla wszystkich, którzy mają wątpliwości, o których wspominałem powyżej, przeznaczone jest drugie rozwiązanie. Mowa o domowym serwerze NAS. Network Access Storage jest to mini-serwer z zamontowanym dyskiem twardym o dużej pojemności, który umożliwia przechowywanie naszych plików. Powstaje pytanie - czy również w tym wypadku do zapisanych plików będziemy mieli dostęp z dowolnego miejsca? Najprawdopodobniej tak - dla niedoświadczonych użytkowników producenci domowych dysków NAS udostępniają aplikacje - dla komputerów i telefonów. Konfiguracja urządzenia, aby współpracowały z takimi programami jest banalnie prosta i sprowadza się do kilku kliknięć. Większość serwerów NAS, nawet tanich, bazuje na Linuksie. Oznacza to całkowitą swobodę w konfiguracji. Jeśli nie chcemy korzystać z aplikacji producentów, możemy sami wyprowadzić odpowiedni ruch na zewnątrz. Przez odpowiednie przekierowania portów na routerze możemy umożliwić dostęp do naszych danych przez Internet. Przykładem taniego NASa jest WD My Cloud. Jeśli mamy trochę więcej pieniędzy, zawsze możemy się skusić na rozwiązania Synology.

Rodzaje kopii zapasowych

Istnieją trzy rodzaje kopii zapasowych: pełna, różnicowa oraz przyrostowa. Czym one się różnią? Zobaczmy:
Kopia pełna, jak sama nazwa wskazuje, zapisuje wszystkie dane. Na przykład, jeśli nasza praca magisterska, mająca 10 megabajtów, zostanie skopiowana z jednego dysku na drugi to będzie to pełna kopia zapasowa. W obydwu miejscach będzie przecież zapisany cały plik. Tzw. full backup ma kilka wad - wykonuje się długo, a jeśli wykonywany jest często, to zajmuje sporą ilość miejsca. Jednakże podstawowa zasada mówi, że abyśmy mogli skorzystać z dwóch pozostałych rodzajów backupu, to najpierw musimy wykonać pełną kopię zapasową.

Kopia różnicowa - Załóżmy, że wcześniej przekopiowaliśmy naszą pracę magisterską na drugi dysk. Następnego dnia wprowadziliśmy w niej szereg zmian. Jeśli następną kopią będzie kopia różnicowa, to zapisany zostanie nie cały plik - a jedynie poczynione przez nas zmiany od momentu wykonania ostatniego pełnego backupu. Kopia różnicowa wykonuje się dość szybko, przywraca się również prędko. Istnieje jednak pewna wada. Przypuśćmy, że następnego dnia w naszej pracy zmieniliśmy tylko jeden wyraz. Nie mniej, w kopii zapasowej z tego dnia będzie odnotowana zmiana tego jednego wyrazu, a także wszystkie inne zmiany dokonane od czasu wykonania ostatniego pełnego backupu. Kopia zapasowa zajmuje więc więcej miejsca, niż faktycznie powinna.

Jako lekarstwo na bolączki kopii różnicowej możemy zastosować kopię przyrostową. Na czym ona polega? Pierwszy incremental backup zapisuje różnice (podobnie jak kopia różnicowa) między wprowadzonymi zmianami a ostatnią pełną kopią zapasową. Różnica w działaniu tych dwóch rodzajów backupu ujawnia się w momencie, kiedy chcemy wykonać drugą kopię przyrostową. Wtedy brane są pod uwagę zmiany wprowadzone nie od momentu pełnego backupu, a od momentu wykonania ostatniej kopii przyrostowej. Dzięki temu miejsce jest bardzo optymalnie wykorzystywane, a czas wykonywania kopii jest bardzo krótki. Podobnie jak każde rozwiązanie, także i to posiada wady. Jest nią długie przywracanie danych i konieczność trzymania wszystkich backupów przyrostowych. Jeśli utracimy jeden z plików - nie przywrócimy danych. (W przypadku kopii różnicowej do przywrócenia danych potrzebujemy jedynie ostatniego backupu różnicowego oraz backup pełny).

Wykonujemy kopię zapasową w Linuksie

Niestandardowo nasze rozważania rozpoczniemy od systemu operacyjnego Linuks. Mamy tutaj do dyspozycji głównie rozwiązania konsolowe. Jednakże, wystarczy je raz dobrze skonfigurować, aby mieć spokój na długi czas. Najpierw nauczymy się wykonywać kopie zapasowe na innym dysku, który posiada linuksowy system plików. Zresztą, jak dobrze wiemy, systemy plików takie jak ext4 czy btrfs są o lata świetlne przed microsoftowym NTFS-em. Zaczniemy od znanego pewnie tutejszej społeczności programu rsync.

Rsync - podstawowa kopia zapasowa

Rsync jest jednym z niewielu darmowych narzędzi posiadających tak ogromne możliwości w zakresie synchronizacji plików. Możemy za jego pomocą robić proste kopie, polegające po prostu na skopiowaniu danych z jedno miejsca na drugie. Dostępna jest możliwość robienia kopii różnicowych czy przyrostowych. Jeśli chcemy, możemy przeglądać także historię zmian. Niestety, narzędzie to jest dostępne jedynie z poziomu wiersza poleceń, co pewnie odstraszy większość osób mniej zaznajomionych z komputerem od jego używania. Jest to błędem, gdyż rsync jest niezwykle prosty w obsłudze.

Załóżmy, że będziemy synchronizowali katalog domowy użytkownika z dyskiem zamontowanym w katalogu /media/dysk_na_kopie.

Zacznijmy od prostej synchronizacji plików między dwoma katalogami (utworzenia pełnej kopii zapasowej). Będziemy musieli użyć polecenia rsync z przełącznikiem -a. Możemy dodać opcję v aby widzieć, co się dzieje podczas tworzenia backupu. Następujące polecenie zrobi pełną kopię zapasową katalogu domowego użytkownika do folderu full_backup na partycji docelowej.

sudo rsync -av /home/karol/ /media/dysk_na_kopie/full_backupPrzyjrzyj się zrzutowi ekranu, który znajduje się nieco wyżej. Zastanówmy się teraz, czy wykonywanie kopii zapasowej folderu Pobrane ma sens? Raczej nie. Wykluczmy niechciane foldery z procesu synchronizacji.

sudo rsync -av --exclude ‘Pobrane’ --exclude ‘Publiczny’ --exclude ‘Pulpit’ /home/karol/ /media/dysk_na_kopie/full_backup

Wynik polecenia widać na screenie powyżej. Tym razem niepotrzebne katalogi nie zostały wzięte pod uwagę podczas procesu synchronzacji.

Wiemy już, jak w najprostszy sposób wykonać pełną kopię zapasową. Co z innymi rodzajami - różnicowymi i przyrostowymi? Za pomocą rsync możemy wykorzystać mechanizm tzw. “twardych powiązań” - hard links. Jeśli dany plik nie został zmodyfikowany od czasu wykonania ostatniego backupu, w najnowszej kopii zostaje powiązany za pomocą twardego powiązania z plikiem z wcześniejszego backupu. Dzięki temu ten sam plik jest zapisywany tylko raz na dysku twardym. Składnia rsync będzie następująca:

sudo rsync -avh --delete --exclude ‘Pobrane’ --exclude ‘Pulpit’ --exclude ‘Publiczny’ --link-dest=/media/dysk_na_kopie/full_backup /home/karol/ /media/dysk_na_kopie/przyrostowa1

Widzimy, że zamiast blisko 14GB zostało przegrane jedynie trochę ponad 100MB. Można byłoby osiągnąć jeszcze lepszy wynik, gdyby z synchronizacji usunąć katalog pamięci cache Chromium. Zerknijmy teraz, jak działa mechanizm “twardych linków”. Przyjrzyj się zrzutowi ekranu, który przedstawia numery inode (węzłów) plików w pełnej kopii zapasowej oraz w przyrostowej

Zauważ, że wszystkie pliki (nie zwracaj uwagi na foldery) mają taki sam numer i-węzła. Różni się on tylko przy pliku: “Dobreprogramy wpis 25.docx”, czyli tym, nad którym aktualnie pracuję (i który zarazem się zmienia). Jaki wniosek można wyciągnąć? Spośród przedstawionych na screenie plików zmienił się tylko jeden, gdyż tylko jeden zapisany jest w innym miejscu systemu plików. Pozostałe pliki w kopii przyrostowej to jedynie “nawiązania” do ich odpowiedników z pełnej kopii zapasowej.

Automatyzujemy wykonywanie kopii zapasowej za pomocą rsync

Jedna z zasad kopii zapasowych mówi o tym, że powinna ona być wykonywana co jakiś czas. Możemy ręcznie wydawać odpowiednie polecenia, ale nie jest to zbyt wygodne. W takim wypadku musimy przecież pamiętać, aby zrobić backup np.: zawsze po wylogowaniu. Nie jest to optymalne rozwiązanie. Właśnie w takim celu można wykorzystać potęgę tkwiącą w skryptach Bash. Za chwilę stworzymy prosty skrypt, który automatycznie raz na dzień wykonuje przyrostową kopię zapasową.

#!/bin/bash #Pobranie obecnego dnia (nazwa katalogu) DZIEN0=`date -I` #Pobranie wcześniejszego dnia (nazwa katalogu): DZIEN1=`date -I -d "1 day ago"` #Źródłowy katalog: ZRODLO="/home/karol/" #Docelowy katalog CEL="/media/dysk_na_kopie/$DZIEN0" KATALOG_LOGOW="/var/log/backup.log" #Link do katalogu docelowego (twardy link) LNK="/media/dysk_na_kopie/$DZIEN1" EXCLUDE="--exclude 'Pobrane' --exclude 'Pulpit' --exclude 'Publiczny'" #Opcje rsync: OPT="-avh --delete $EXCLUDE --link-dest=$LNK --log-file=$KATALOG_LOGOW" #Uruchamiamy backup rsync $OPT $ZRODLO $CEL #Ustalamy nazwę katalogu kopii starszej niż 14 dni DZIEN14=`date -I -d "14 days ago"` #Kasujemy backup starszy niż 14 dni if [ -d /media/dysk_na_kopie/$DZIEN14 ] then rm -rf /media/dysk_na_kopie/$DZIEN14 fi

Przeanalizujmy pokrótce, co się dzieje w powyższym skrypcie. Najpierw tworzymy kilka zmiennych, które będą naszymi nazwami katalogów. Kolejne zmienne definiują odpowiednio: co będziemy backupowali oraz gdzie. W katalogu logów zapisujemy wyniki działania polecenia - przydatne, jeśli będziemy chcieli znaleźć przyczynę ewentualnych błędów. Zmienna OPT przechowuje parametry, z którymi zostanie wywołane polecenie rsync. Po wykonaniu odpowiednich definicji możemy w końcu uruchomić backup.

Ostatnie 6 linijek odpowiada za kasowanie kopii zapasowych starszych niż 14 dni. Stanowi to zabezpieczenie przed zbytnim zużyciem miejsca na dysku przez bardzo stare wersje plików.

Pozostaje nam ostatnia rzecz - musimy poinformować system, kiedy nasz skrypt ma być uruchamiany. Dostępnych jest wiele opcji. My zapiszemy nasz skrypt w katalogu /etc/cron.daily. Dzięki temu kopia zapasowa będzie wykonywana raz dziennie.

Duplicity - backup z wieloma możliwościami

Rsync jest bardzo prostym programem. Niestety, za jego pomocą nie wykonamy kopii przyrostowych na zasobach udostępnionych przez protokół CIFS (dla niewtajemniczonych – pliki udostępnione przez Sambę lub Windowsa). Dodatkowo, omawiany wcześniej program nie wspiera ani automatycznej kompresji danych ani szyfrowania. Powstaje pytanie, co zrobić w przypadku, kiedy chcemy wykonać kopię zapasową poufnych danych na niepewny nośnik? Taki backup powinniśmy zawsze wykonywać w miejscu, do którego jedynie my mamy dostęp. Jednakże, nie zawsze istnieje taka możliwość. W takim wypadku musimy polegać na sile kryptografii. Możemy ręcznie szyfrować każdy plik, ale byłoby to niezwykle czasochłonne zajęcie. Programiści opracowali dla nas odpowiednie oprogramowanie. Jedną z darmowych opcji jest zastosowanie programiku działającego podobnie jak rsync, a noszącego nazwę Duplicity.

Instalacja oprogramowania jest bardzo prosta i możemy to zrobić za pomocą standardowego wywołania apt-get.

Naszym pierwszym zadaniem będzie osiągnięcie efektu podobnego jaki uzyskaliśmy przy pomocy rsync. Będziemy synchronizowali nasz katalog domowy z folderem /media/katalog_na_kopie/kopia. Polecenie służące do tego celu będzie wyglądało następująco:

duplicity --no-encryption /home/karol file:///media/dysk_na_kopie/kopia

Wynik działania programu został przedstawiony na screenie. W przeciwieństwie do rsync, otrzymujemy o wiele więcej informacji na temat przeprowadzonych przez program działań. Wiemy m.in. ile plików zostało zmienionych od czasu wykonania ostatniej pełnej kopii zapasowej, ile zajmują dane przed i po kompresji, a także wiele innych rzeczy. Przykładowe polecenie także doskonale pokazuje podstawową składnię duplicity. Najpierw podajemy przełączniki, których zamierzamy użyć. Wyłączyliśmy szyfrowanie za pomocą opcji –no-encryption. Dlaczego? Nie możemy w tej chwili użyć szyfrowania, gdyż jeszcze nie wygenerowaliśmy odpowiednich kluczy.

Duplicity współpracuje z wieloma protokołami. My, w przykładzie powyżej użyliśmy protokołu file://. Służy on po prostu do wykonania kopii zapasowej zapisanej w jakimś miejscu w naszym drzewie katalogów. Możemy skorzystać z innych protokołów, np.: ftp czy scp. Nie stanowi to żadnego problemu.

Analizujemy kopię zapasową duplicity i przywracamy dane

Rsync to w założeniach narzędzie do synchronizacji dwóch katalogów. Rolę programu do wykonywania kopii zapasowych nadaliśmy mu my, używając odpowiednich przełączników i sztuczek. W przeciwieństwie do rsync, duplicity jest aplikacją opracowaną od początku do końca z myślą o backupie. Dostarcza dzięki temu szereg przełączników, służących do analizy zawartości backupów, a także czasu ich wykonania. Teraz poznamy kilka podstawowych przełączników służących do tego celu.

Wykonujemy backupy. Bardzo przydatna byłaby wiedza, jakie kopie zapasowe, z jakich okresów posiadamy na swoim nośniku. Możemy poznać te informacje za pomocą następującego polecenia:

duplicity collection-status file:///media/dysk_na_kopie/kopia

Wynik działania polecenia widzimy na screenie powyżej. Przełącznik collection-status dostarcza informacji na temat rodzaju oraz daty wykonania kopii zapasowych.

Czasami chcemy wyświetlić historię modyfkacji danego pliku na przestrzeni ostatnich kilku backupów. Listę wszystkich plików znajdujących się w kopiach zapasowych możemy wyświetlić za pomocą polecenia:

duplicity list-current-files file:///media/dysk_na_kopie/kopiaIstnieje jeden problem. Chodzi nam przecież o konkretny plik, a nie o wszystkie! Musimy przefiltrować to, co wyrzuca duplicity za pomocą polecenia grep. Przypuśmy, że chcemy poznać historię modyfikacji pliku zawierającego słowa “Bazy danych.docx”. Powinniśmy użyć polecenia:duplicity list-current-files file:///media/dysk_na_kopie/kopia | grep ‘Bazy danych.docx’

Wynik polecenia jasno wskazuje że plik ten występuje tylko raz w naszej kopii zapasowej. Znamy także datę jego ostatniej modyfikacji.

Zostaje nam ostatni problem do rozważenia - jak przywrócić pliki z kopii zapasowej wykonanej za pomocą duplicity? Zacznijmy od przywrócenia zawartości całego folderu. Służy do tego następujący ciąg znaków:

duplicity --no-encryption --file-to-restore Dokumenty file:///media/dysk_na_kopie/kopia /home/karol/Dokumenty/kopiaJaka jest składnia? Poznaliśmy nowy parametr --file-to-restore. Informuje on duplicity o tym, że chcemy przywrócić dane. --no-encryption zastosowaliśmy dlatego, że nasza kopia zapasowa nie była szyfrowana. Następnie podajemy nazwę folderu, który chcemy przywrócić. Potem jedynie zapisujemy źródło oraz cel. Voila! Plan został wykonany. Podobnie postępujemy, jeśli chcemy przywrócić pojedynczy plik.

Powstaje pytanie - co zrobić, jeśli chcemy przywrócić nie najnowszą wersję pliku, ale np.: taką sprzed 10 dni? Polecenie będzie takie samo jak te powyżej. Musimy dodać jedynie przełącznik -t, po której podajemy wiek pliku. Przykładowo, chcemy przywrócić plik bazy_danych.docx sprzed 10 dni. Polecenie będzie wyglądało następująco:

duplicity --no-encryption --file-to-restore -t 10D Dokumenty/bazy_danych.docx file:///media/dysk_na_kopie/kopia /home/karol/Dokumenty/bazy_danych.docx

Szyfrujemy kopię zapasową

Duplicity jest narzędziem nie tylko o wiele wygodniejszym od rsynca, ale dającym “out-of-the-box” wiele więcej możliwości. Jedną z najważniejszych jest możliwość szyfrowania naszych kopii zapasowych, jeśli zapisujemy je na niezaufanym medium. Konfiguracja jest, podobnie jak w poprzednich wypadkach, niezwykle prosta.

Omawiany program może korzystać z szyfrowania za pomocą gpg. GPG (GNU Privacy Guard), funkcjonuje podobnie jak TLS używany w przeglądarkach. Do szyfrowania niezbędna jest para kluczy publiczny-prywatny. Klucz prywatny należy chronić przed osobami trzecimi, gdyż pozwala odczytać zaszyfrowane za pomocą klucza publicznego dane.
Aby użyć GPG, najpierw musimy wygenerować klucze. Robimy to za pomocą polecenia:gpg --gen-key

Najpierw wybieramy rodzaj klucza, który będzie używany do właściwego szyfrowania. Domyślną opcją jest algorytm RSA. Szyfrowanie Elgamala jest pewniejsze, ale pochłania większą ilość mocy obliczeniowej. Załóżmy, że wybraliśmy domyślną opcję: RSA i RSA.

Kolejnym krokiem będzie wybranie długości klucza. Logiczne jest, że klucz jest tym bezpieczniejszy, im dłuższy. Toteż najlepiej wybrać największą wartość - 4096 bitów.

Następnie wybieramy okres ważności klucza. Ten fakt zależy w całości od nas. Jeśli nie będzie istniało zbyt duże ryzyko wycieku, możemy ustawić dłuższy czas ważności. W przeciwnym wypadku lepiej częściej wymieniać klucze szyfrujące, choć z pewnością jest to bardziej kłopotliwe.

Pozostaje przed nami jeden z ostatnich kroków. Musimy wypełnić dane osobowe. Zapisane one będą w pliku klucza publicznego, jednoznacznie deklarując jego właściciela.

Po wypełnieniu kilku pól możemy, ale nie musimy wpisać klucz, którymi będziemy chronić nasz klucz prywatny. Jest to kolejna opcja, której możemy użyć dla zwiększenia bezpieczeństwa naszych danych.
Najgorszym i najbardziej denerwującym etapem generowania klucza jest entropia. Co to jest? W skrócie, generator liczb losowych, podobnie jak wszystko w informatyce, musi polegać na jakimś algorytmie. GPG jako “ziarno” do generatora liczb losowych wprowadza różne dane, związane np.: z tym, co aktualnie robimy przy komputerze, jakie znaki na klawiaturze wpisujemy itp. Czym większa entropia, tym większe bezpieczeństwo klucza. GPG nie wygeneruje nam klucza dopóty, dopóki nie będzie miał odpowiedniego zasobu “losowych” informacji. Ten etap jest stosunkowo najdłuższy.

Po wygenerowaniu klucza zostanie wyświetlone podsumowanie związane z wykonywaną operacją. Są to bardzo podstawowe dane, związane np.: z datą wygaśnięcia klucza czy danymi właściciela. Najważniejszym parametrem, który później znajdzie zastosowanie w duplicity, jest identyfikator klucza, zaznaczony na screenie powyżej. Będziemy musieli go podać jako parametr w ciągu argumentów duplicity. Dzięki temu nasz backupowy program będzie wiedział, jakiego klucza ma użyć. Przykładowa linia poleceń może wyglądać tak:duplicity --encrypt-key 737A2398 /home/karol file:///media/dysk_na_kopie/kopia

Jeśli chcemy przywrócić plik, używamy takich samych poleceń jak w poprzednim rozdziale. Jedyną różnicą jest zastąpienie parametru --no-encryption opcją --encrypt key xxx.

DODATEK A: Montujemy zasób sieciowy używający protokołu SMB na stałe

Za pomocą duplicity możemy bardzo prosto wykonywać kopię zapasową na nasz dysk sieciowy. Niestety, aby to zrobić, musimy najpierw uruchomić automatyczne montowanie zasobu w odpowiednim katalogu.

Zadanie to jest niezwykle proste. Nie znaczy to, że nie będziemy musieli doinstalować dodatkowego oprogramowania i pobawić się w konsoli. Pakietem, który powinniśmy zainstalować jest cifs-utils. Następujące polecenie wykona to zadanie:

sudo apt-get install cifs-utilsPrzejdźmy teraz do katalogu media, znajdującego się w głównym drzewie katalogów. Utwórzmy tam folder: katalog_na_kopie.

Teraz czeka nas najcięższy etap zadania. Musimy dodać odpowiedni wpis do /etc/fstab. W tym pliku są zapisane wszystkie zasoby/dyski, które należy zamontować podczas startu systemu. W naszym wypadku musimy dopisać linijkę odpowiedzialną za automatyczne montowanie udostępnionego przez dysk sieciowy zasobu. W moim wypadku wyglądałaby następująco:

//192.168.1.6/karol /media/katalog_na_kopie cifs username=karol,password=supertajnehaslo,iocharset=utf8,sec=ntlm 0 0Zamiast //192.168.1.6/karol Podstawiamy nasze dane - odpowiednio - adres IP/nazwę serwera oraz nazwę udostępnionego zasobu. Parametrów username i password możesz zastąpić słówkiem guest w wypadku, gdy udostępniony folder nie jest chroniony hasłem.
Fstab jest plikiem, który każdy z użytkowników może podejrzeć. Przechowywanie w nim hasła do zasobu sieciowego nie jest zbyt dobrym pomysłem. Przenieśmy więc je do oddzielnego, ukrytego pliku o nazwie smbcredentials, znajdującego się w naszym katalogu domowym. Wydajemy polecenia:

touch ~/.smbcredentials nano ~/.smbcredentialsTreść powinna wyglądać następująco:username=karol password=supertajnehasloOczywiście za słowa karol i supertajnehaslo powstawiasz własne parametry - odpowiednio login oraz hasło do zasobu.

Teraz musimy jedynie zakazać wszystkim użytkownikom (oprócz nas) dostępu do tego pliku, a nawet jego oglądania. Robimy to za pomocą szeroko znanego polecenia chmod:chmod 600 ~/.smbcredentialsWiększość operacji została wykonana. Teraz musimy jedynie przeprowadzić edycję pliku /etc/fstab. Zamiast parametrów username i password należy użyć opcji credentials, która jako argument przyjmuje ścieżkę do naszego pliku z parametrami logowania. W praktyce wyglądać to będzie następująco:

//192.168.1.6/karol /media/katalog_na_kopie cifs credentials=/home/karol/.smbcredentials,iocharset=utf8,sec=ntlm 0 0

Słowem podsumowania

Oprócz dwóch wyżej opisanych, na Linuksa dostępnych jest wiele więcej innych narzędzi. Niestety, nie wyróżniają się one żadnymi funkcjami, których nie udostępniałby rsync lub duplicity. Niefortunnie, w tej części zabrakło miejsca dla Windowsa. Także, jeśli chcesz poczytać trochę o wykonywaniu kopii zapasowych na systemie operacyjnym z Redmond, zarówno za pomocą wbudowanych jak i dodatkowych narzędzi, zapraszam na kolejną (i prawdopodobnie ostatnią) część dotyczącą kopii zapasowych.
 

linux bezpieczeństwo porady

Komentarze

0 nowych
takijeden.ninja   5 #1 16.09.2016 19:49

Jeśli jeszcze nie znasz to zerknij na BURPa.
Tu masz linka: http://burp.grke.org/
a tutaj UI: http://git.ziirish.me/ziirish/burp-ui

Autor edytował komentarz w dniu: 16.09.2016 19:49
NieGooglujMnie   6 #2 16.09.2016 20:53

Na Linuxie od lat bez zmian:
rsync, cron, dobrze skonfigurowany SSH
rpi3
FreeFileSync

jeszcze myślę o OwnClod + rpi3:
http://malinowepi.pl/post/41015203413/owncloud-czyli-nasz-prywatny-dropbox

do ogólnych zabaw polecam również webmina:
http://www.webmin.com/
no i Sambę ;)

Autor edytował komentarz w dniu: 16.09.2016 20:56
adamk1985   11 #3 16.09.2016 20:59

Bardzo ciekawy wpis. Przyda się kiedyś z pewnością.

saturno   9 #4 16.09.2016 21:02

//Niestety, narzędzie to jest dostępne jedynie z poziomu wiersza poleceń, co pewnie odstraszy większość osób mniej zaznajomionych z komputerem od jego używania. Jest to błędem, gdyż rsync jest niezwykle prosty w obsłudze.//

Skończyłem czytać artykuł na powyższym tekście bo:
https://screenshots.debian.net/package/grsync
https://screenshots.debian.net/package/luckybackup
https://screenshots.debian.net/package/unison-gtk
Tylko tyle, albo aż tyle nakładek na tym "trudnym" Debianie!

dr.boczek   7 #5 16.09.2016 21:28

ja również korzystam z rsync - mniej więcej z takiego rozwiązania - backup robię na zdalnych serwerach.
https://www.digitalocean.com/community/tutorials/how-to-copy-files-with-rsync-ov...

muska96   8 #6 16.09.2016 21:44

Wpis prosty, czytelny i przydatny. Dobra robota. Gdybym miał jeszcze jakiś dysk do backupu, to robiłbym pełny, a tak muszę się zadowolić kopią wyłącznie najważniejszych.

@NieGooglujMnie Zamiast OwnCloud polecam Seafile - jest trochę szybsze i łatwiejsze do skonfigurowania - używam ma RPi Zero i jest wg mnie lepsze od OwnClouda.

NieGooglujMnie   6 #7 16.09.2016 22:29

@muska96: "Seafile"

łatwość skonfigurowania nie ma znaczenia (obydwa są banalne), ale szybkość ma znaczenie ;)

wiesz może w jakich językach napisane jest Seafile ?
kompatybilne z Androidem? Debianem? Rpi 3 ?

Autor edytował komentarz w dniu: 16.09.2016 22:31
muska96   8 #8 17.09.2016 00:38

@NieGooglujMnie Nie jestem pewien, ale chyba w Django i PHP (albo samym Django - już nie pamiętam). Jest aplikacja na androida, na Debiana powinna być (jest nawet na Fedorę - napisana w QT5) I skoro poszła mi na RPi Zero, to czemu nie na RPi 3? Jest otwartożródłowa jak OwnCloud, więc nie ma problemu.

NieGooglujMnie   6 #9 17.09.2016 10:02

@muska96:

ja przyznam się, że sam nie wiem do końca z czego korzystać.

Z jednej strony jest sshfs : czyli mountowanie dysków po protokole SSH. Jak się to dobrze ustawi, to nie ma bugów. Można też zrobić zdalnie, nawet ze zmiennym adresem IP.
https://play.google.com/store/apps/details?id=ru.nsu.bobrofon.easysshfs&hl=pl
SSHFS jest na Androida, ale nie ma na Windowsa, co mnie akurat nie interesuje bo nie mam Windowsa.

Z drugiej strony jest zwykłe rsync, które można upchać do crona.

Lokalnie jest zawsze niezawodna Samba, której konfiguracja przez webmin to kwestia 2 minut.

mamy nakładki GUI na rsync, jak już ktoś wspomniał, np. unison:
https://www.cis.upenn.edu/~bcpierce/unison/

jest też FreeFilesSync, który dobrze działa na Linuxie:
http://www.freefilesync.org
i który ma deamona którego można dać do kalendarza, a więc można to nieźle skonfigurować żeby chodziło regularnie.

No i załozyłem kiedyś topic:
https://forum.dug.net.pl/viewtopic.php?id=28711
w którym ludzie wymienili:
dd
fsarchiver, fsarchiver QT (GUI)
LiveCD zwane CloneZilla
dystrybucja Redo Backup

No i może to dziwnie brzmi, ale jeszcze są zwykłe kopie (scp, cp) i np. dodać do tego zipowanie i schedulowanie w cron.

Jest możliwość zrobienia VPN na rpi i podpinanie się do VPN, co powoduje, że wszystkie komputery są jakby w jednej sieci (nawet zdalnie) - czyli można poprzez VPN zdalnie sobie dodać sambę bądź inne narzędzia z LANa.

Więc tak naprawdę mamy z 15 różnych rozwiązań, no i teraz pytanie które najlepsze ;)

Autor edytował komentarz w dniu: 17.09.2016 10:15
muska96   8 #10 17.09.2016 11:44

@NieGooglujMnie Najbezpieczniejsze z tych wszystkich wydaje się VPN + Samba, ale traci się na wygodzie. Nie wiem, jak RSync działa na androidzie. CloneZilla jest niewygodna, a używanie dd do backupu wymaga ogromu miejsca. Słyszałem też o SyncThing, ale nie wiem, czy jest on otwarty.

Jeśli chcesz mieć dostęp z każdego komputera bez konieczności konfigurowania wszystkiego, a jednocześnie dobry dostęp w sieci lokalnej to:
- Postaw Sambę + VPN
- do tego dodaj np. Seafile + seafile FUSE - wadą jest to, że pliki byłyby dostępne tylko do odczytu, ale ułatwia to sytuację z synchronizacją (Seafile robi bazę plików, przez co nie da się tak łatwo wrzucić plików po prostu kopiując do nowego katalogu)

Ewentualne, jeśli uwielbiasz robić wszystko drogą Uniksową, to wrzuć rsync + cron.

Jak chcesz, to możesz sprawdzić jeszcze BitTorrentSync, ale nie ma dostępnego kodu chyba.

Kiedyś testowałem Nimbus Cloud na moim RPi i mimo, że jest on napisany w Javie i wykorzystuje Jetty, pracował bardzo sprawnie, ale przeglądarka bez JavaScriptu go nie otworzy, a i klienty synchronizacji są jakie są. No i ma jako licencję EULA, co raczej wyklucza go do mojego zastosowania.

Aż się przypomina https://xkcd.com/927/ :D

  #11 17.09.2016 12:30

Wpis ciekawy, ale po co sobie aż tak komplikować życie? Ja podpinam dysk zewnętrzny do USB i zwyczajnie kopiuję swoje pliki (nawet przyrostkowo) z dysku lokalnego na zewnętrzny. Nie ufam żadnym serwerom online.

Autor edytował komentarz.
mktos   9 #12 17.09.2016 12:54

@muska96: SyncThing jest otwarty, w przeciwieństwie do BTSync właśnie.

CloneZilli/partclone/dd używałbym tylko jeżeli potrzebne jest pełna kopia systemu - ale równie dobrze można tylko utrzymywać kopie danych i konfiguracji oraz mieć gotowe skrypty "stawiające" system od zera (Puppet, Chef).

@mnemosyne: Warto mieć kopię poza jednym miejscem fizycznym - będzie pożar czy powódź i tracisz swoje dane oraz ich kopię, jeżeli była przechowywana obok.

  #13 17.09.2016 13:17

@mktos: ok, jestem za NAS, ale dyskom online nie ufam, jak już pisałem.

ciesiel   4 #14 17.09.2016 16:50

W poważniejszych zastosowaniach gdzie mamy mieszane środowiska (windows, linux itp. - np. w firmach) polecałbym jeszcze zainteresować się Baculą.

  #15 17.09.2016 17:11

@ciesiel: chyba BareOS ;)

SpeX   6 #16 17.09.2016 18:03

@karol221-10 A próbował byś się pobawić z amazon cloud drive?
a) robienie tam kopi
b) rozszerzenie przestrzenni dyskowej tam, tz. bym nie musiał trzymać /media/video na HDD, tylko tam a jedynie synchronizował to co chcę teraz oglądać - w tej chwili do tego wykorzystuję odrive.

Oczywiście z szyfrowaniem zawartości, bo niestety darmowo odrive tego nie oferuje.

Autor edytował komentarz w dniu: 17.09.2016 18:04
  #17 17.09.2016 20:08

a może by tak wpis o migawkach plików i ich przywracaniu na btrfs?

  #18 17.09.2016 22:38

polecam svg lub gita proste wygodne przenosne (nawet dyski fat)

  #19 17.09.2016 23:49

@muska96: SyncThing jest otwarty. Co do ogromu miejsca na backup przy pomocy dd, to dd jest do specyficznego zadania: Zrobienia kopii całkowitej, a nie inkrementalnej. Da się przy pomocy dd i SquashFS zrobić i spakowane obrazy które się da zamontować (http://martin.elwin.com/blog/2008/05/backups-with-squashfs-and-luks/ czy http://oldcomputer.info/log/index.php?id=20160720145016-mountable-compressed-ful...) ale nadal nie ma co myśleć o tym, że jakikolwiek system zrobi inkrementalną kopię spakowanego obrazu. Trzeba by się wpiąć wymiennymi blokami między kompresję systemu plików (SquashFS) a pakowanym obrazem. Pewnie się da montując SQFS, ale powyższe dwa sposoby próbowałem i potwierdzam, że działają.

  #20 18.09.2016 09:07

Na windows jak i linuxie używam freefilesync i sobie chwalę

karol221-10   9 #21 18.09.2016 10:53

@SpeX Zobaczymy, na ten miesiąc i następny mam zaplanowanych kilka innych tematów, ale chmura od amazonu też może być ciekawa.

Autor edytował komentarz w dniu: 18.09.2016 10:54
  #22 18.09.2016 13:59

a ci dalej bez terminala nie są w stanie nic zrobić xD co za żenada

elita   4 #23 18.09.2016 15:01

Ja starej daty, więc tar+nfs :) rsync też - ale to nowość ;)
W cloudy nie ufam, szczególnie pod kątem wycieku danych, błędów, implementacji itd.
Czy jakiś *cloud oferuje zdalne urządzenie blokowe? W sensie tak aby na tym postawić np luks czy inny kryptowolumen sieciowy (z szyfrowaniem po stronie klientów).

pan_jez   3 #24 18.09.2016 15:56

Bardzo przydatny artykuł.

Ja polecę Veeam Endpoint Backup (wersja dla Linuksa to beta, ale działa aż miło, Windows ma go już w wersji stabilnej): https://www.veeam.com/blog/how-to-backup-linux.html
Sporym plusem rozwiązania jest obsługa wersjonowania, do tego deduplikacja, kompresja i backupy przyrostowe oparte o ich własnościowe rozwiązanie zwane CBT - Changed Blocks Tracking. Uzywam od jakiegoś czasu zarówno pod Windows jak i Linuksem i jak na coś zupełnie darmowego, to jest świetne, a do tego pozwala na bare-metal-restore, czyli 100% odtworzenie całej maszyny od zera do stanu z ostatniego backupu w przypadku jakiejś katastrofy, nawet na dysk o mniejszym rozmiarze niż oryginał.
W ogóle jeśli chodzi o rozwiązania do backupu, to mają naprawdę świetną ofertę, a oferowane przez nich darmowe opcje są według mnie bezkonkurencyjne, wspomnę choćby VeeamZIP - backup dla Hyper-V i VMWare.

Autor edytował komentarz w dniu: 18.09.2016 15:56
  #25 18.09.2016 18:13

Wspaniałą pracę "odwaliłeś" z tym tekstem, brawo. Czyta się świetnie, no i treściowo bardzo bogato. Dzięki.

dragon321   9 #26 18.09.2016 20:02

Są GUI dla rsync.

A poza tym, to całkiem dobry wpis. Zapiszę go sobie, może i się przyda kiedyś.

  #27 18.09.2016 21:30

Jest też potężny DAR (Disk Archiver), który robi kopie zapasowe do skompresowanych, opcjonalnie zaszyfrowanych archiwów (*.dar). Program jest dostępny pewnie w większości dystrybucji.
Adres: http://dar.sourceforge.net/

Tu jeszcze kikla uwag odnośnie programów tego typu na linuksie:
http://www.halfgaar.net/backing-up-unix

watchmaker   4 #28 18.09.2016 22:28

Wszyscy klaskają uszami ale dwóch baboli w skrypcie jeszcze nikt nie zauważył? Dobrze o Was świadczy, klaskajcie dalej.

  #29 19.09.2016 08:52

Czemu piszecie takie bzdury? Jednym z pierwszych pytań jakie zadaje system po instalacji Ubuntu jest pytanie o konfigurację kopi zapasowej. Wszystko działa w środowisku graficznym.

  #30 19.09.2016 09:17

@muska96: Jest super, też go używałem, ale niestety ma poważną wadę - wymaga Javy.

  #31 19.09.2016 10:47

faktycznie są babole a dodatkowo jaka bedzie mozliwosc odtworzenia backupu jezeli po 14 dniach usuniemy pliki hardlinkowane? skrypt wymaga duzej poprawki

gaijin   4 #32 19.09.2016 11:25

@karol221-10: nie napisałeś jak przywrócić kopię zapasową przyrostową poprzez rsync...

Viperoo   7 #33 19.09.2016 11:43

Ja bym użył jeszcze snapshotów w btrfs/zfs.

karol221-10   9 #34 19.09.2016 13:39

@gaijin: Nie napisałem tego dosłownie - fakt. Po prostu wchodzisz do katalogu, gdzie kopia się zapisuje i kopiujesz potrzebne ci pliki do np.: katalogu domowego
@watchmaker: Jak zawsze konstruktywna krytyka :) Dzięki za zwrócenie uwagi na błąd. Ten skrypt śłużył mi wcześniej bardziej w formie proof-of-concept. Nie zauważyłem, że nie zmieniłem ścieżki w kilku miejscach. Poprawię.
@szon (niezalogowany): Ubuntu posiada co prawda wbudowane narzędzia do robienia kopii zapasowych, ale nie testowałem, jak one działają. Dlaczego? Jak dla mnie, Ubuntu w nowszych wersjach jest nieużywalne przez interfejs Unity. Może i sam Unity bym przełknął, ale komunikatów "Wystąpił błąd wewnętrzny systemu" wyskakujących co kilka minut już nie.
@Viperoo W przyszłości (bliżej nieokreślonej, zależy od tego, ile będę miał czasu. W końcu klasa maturalna zobowiązuje) zamierzam w ogóle wziąć na warsztat "cechy specjalne" linuksowych i windowsowych systemów plików.

Autor edytował komentarz w dniu: 19.09.2016 13:46
  #35 19.09.2016 14:34

Moją kopią zapasową jest GitHub ;)
A jeżeli chodzi o prywatne projekty/dane to specjalnym skryptem robie push-a na 3 pendrajwy trzymane w 3 różnych miejscach w tym jeden poza budynkiem.

look997   6 #36 19.09.2016 16:24

Czy Deja Dup jest dobry? Czy może mają jakieś problemy?
Na razie robię nim kopie ale nie miałem okazji przywracać. Wszystko będzie ok?

watchmaker   4 #37 19.09.2016 18:13

@karol221-10: Karol, wbrew pozorom jestem fanem. Robisz dobrą robotę, brakuje Ci jednak "polerki" i - czasem - dokładności. Ale wyrobisz się, o to się nie martwię. Został jeszcze jeden błąd, podpowiem niesubtelnie, że jest to linijka w zupełnie zbędnym if-ie (tak, ten if nie jest potrzebny, nie przeszkadza, ale mogło by go nie być).

karol221-10   9 #38 19.09.2016 18:44

@watchmaker: Poprawione :) Co do ifa, wiem może nie jest tak bardzo potrzebny (sprawdza, czy katalog istnieje) ale dla formalności go umieściłem.
@look997: Deja Dup używałem, aczkolwiek bardzo krótko, więc wiele o nim powiedzieć nie mogę. O ile nie sypie się tak jak Unity (na niektórych konfiguracjach sprzętowych) to wszystko powinno być ok.

Autor edytował komentarz w dniu: 19.09.2016 18:44
NieGooglujMnie   6 #39 19.09.2016 19:49

@muska96:

mam pytanie jeszcze (jakbyś przeczytał, to fajnie) - jak zachowuje się w htop/top to twoje Seafile ?
ile żre ramu?

chcę się pobawić OwnCloud, ale przekonujesz mnie że to co zaproponowałeś lżejsze jest i szybsze (znaczący argument)

OwnCloud to w sumie kombajn jest, a na RPI wiadomo jak z zasobami

Autor edytował komentarz w dniu: 19.09.2016 19:50
muska96   8 #40 19.09.2016 20:45

@NieGooglujMnie Nie jest specjalnie żarłoczny na RAM - podczas ładowania strony bierze ok 50 MB RAM, ale tylko, gdy ładuje stronę. Niestety jest żarłoczny na CPU, przez co nie chodzi tak szybko jak np. nimbus cloud, który mimo wszystko jest napisany w Javie. Jeśli masz RPi 2 lub wyższe, to nie ma problemu.

Na htop przed ładowaniem strony miałem ok 133MB, a podczas sesji do 171MB, więc nie ma z tym problemu - powinno dać sobie radę z lepszym Raspberry bez żadnych opóźnień. Ale tak jak pisałem CPU skacze do 100% przy pierwszym ładowaniu strony.

Autor edytował komentarz w dniu: 19.09.2016 20:48
  #41 20.09.2016 15:40

@watchmaker: Nie każdy analizuje cały skrypt. Niektórzy tutaj tylko przeczytali newsa.

watchmaker   4 #42 21.09.2016 20:22

@Anonim (niezalogowany): Anonim (niezalogowany): No, żebyś się nie zmęczył

addos   8 #43 24.09.2016 13:30

@hahahahah (niezalogowany): "a ci dalej bez terminala nie są w stanie nic zrobić xD co za żenada"

A w czym ci to tak mocno przeszkadza? Zabroniono tego prawnie ostatnio, czy co?