Backup idealny z Borg – cz. I: omówienie i przygotowanie repozytorium

Czy istnieje idealne rozwiązanie, zapewniające pewne kopie zapasowe? Do tego darmowe, szybkie i bezpieczne. Pewnie nie, ale postaram się przybliżyć jedno z rozwiązań, które według mnie jest temu bliskie i od kilku lat skutecznie zapewnia kopie kilkudziesięciu naszym serwerom.

Wstęp

Rozwiązanie to oprzemy o oprogramowanie BorgBackup (w skrócie Borg), które oferuje między innymi deduplikację z szyfrowaniem i kompresją (LZ4, zlib, LZMA, zstd), jest darmowe – na wolnej licencji BSD. Kopie zapasowe umieścimy na zewnętrznym serwerze, z którym komunikować się będziemy przez bezpieczny protokół SSH.

Repozytorium kopii zapasowych (bo tak raczej należy to nazywać) można wygodnie zamontować na dowolnej uprawnionej kluczem maszynie dzięki FUSE (Filesystem in Userspace) – bezpośrednio jako wybraną kopię z konkretnego dnia lub całościowo i ręcznie wybrać pożądaną kopię zapasową.

W praktyce przykładowa, codzienna kopia dużej ilości plików – o łącznej zajętości około 500GB, wykonuje się w około 18-20 minut, a miejsce zajęte dla 7 kopii codziennych + 4 kopii z tygodnia zajmuje razem nieco ponad 850GB. Są to wartości zmierzone na rzeczywistym systemie produkcyjnym, który równolegle w tym czasie wykonuje sporo innych czynności więc wydajność na maszynie, która jest mniej obciążona byłaby jeszcze większa.

Instalacja

Borg jest dostępny w wielu repozytoriach dystrybucji Linuksa, ale również do pobrania w formie gotowych plików binarnych, które są przygotowane dla Linuksa, FreeBSD oraz MacOSX. Wybieramy pliki ze strony – znajdziemy je tutaj: https://www.borgbackup.org/releases/

Po wybraniu najnowszej stabilnej wersji (w momencie pisania artykułu jest to 1.1.16) pobieramy odpowiedni plik – w moim przypadku będzie to plik borg-linux64 i jeżeli chcemy to również możemy pobrać plik borg-linux64.asc aby sprawdzić podpis PGP pliku.

Zaczynamy od importu klucza PGP:

gpg --recv-keys "6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393"
 gpg: zapytanie o klucz FAF7B393 w serwerze hkp keys.gnupg.net
 gpg: klucz FAF7B393: klucz publiczny ,,Thomas Waldmann tw@waldmann-edv.de'' wczytano do zbioru
 gpg: brak absolutnie zaufanych kluczy
 gpg: Ogółem przetworzonych kluczy: 1
 gpg:          dołączono do zbioru: 1  (RSA: 1)

Pobieramy pliki:

wget -q --show-progress https://github.com/borgbackup/borg/releases/download/1.1.16/borg-linux64
wget -q --show-progress https://github.com/borgbackup/borg/releases/download/1.1.16/borg-linux64.asc

Weryfikujemy pobrany plik binarny:

gpg --verify borg-linux64.asc

 gpg: przyjęto obecność podpisanych danych w 'borg-linux64'
 gpg: Podpisano w pon, 22 mar 2021, 23:49:57 CET kluczem RSA o numerze 51F78E01
 gpg: Poprawny podpis złożony przez ,,Thomas Waldmann tw@waldmann-edv.de''
 gpg:        alias ,,Thomas Waldmann tw-public@gmx.de''
 gpg:        alias ,,Thomas Waldmann twaldmann@thinkmo.de''
 gpg:        alias ,,Thomas Waldmann thomas.j.waldmann@gmail.com''
 gpg: OSTRZEŻENIE: Ten klucz nie jest poświadczony zaufanym podpisem!
 gpg:              Nie ma pewności co do tożsamości osoby która złożyła podpis.
 Odcisk klucza głównego: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393
       Odcisk podklucza: 2F81 AFFB AB04 E11F E8EE  65D4 243A CFA9 51F7 8E01

Wygląda więc na to, że plik jest poprawny i możemy bezpiecznie go zainstalować.

sudo cp borg-linux64 /usr/local/bin/borg
sudo chown root:root /usr/local/bin/borg
sudo chmod 755 /usr/local/bin/borg

Sprawdzamy poprawność instalacji:

borg -V
 borg 1.1.16

Przygotowanie serwera

Możemy zatem przejść dalej i przygotować sobie nasze repozytorium na zdalnym serwerze backupowym, który dla bezpieczeństwa powinien pozwalać tylko na dostęp przez ssh i najlepiej tylko z poziomu naszego komputera/serwera.

Aby móc komunikować się z repozytorium bez ręcznego logowania musimy wygenerować nasz klucz publiczny – poleceniem ssh-keygen. Powinniśmy zobaczyć coś podobnego do tego:

Generating public/private rsa key pair.
 Enter file in which to save the key (/home/user/.ssh/id_rsa): 
 Enter passphrase (empty for no passphrase): 
 Enter same passphrase again: 
 Your identification has been saved in /home/user/.ssh/id_rsa.
 Your public key has been saved in /home/user/.ssh/id_rsa.pub.
 The key fingerprint is:
 41:10:72:3d:34:ee:2d:52:32:46:f3:b9:4f:d2:7b:3b user@linux.pl
 The key's randomart image is:
 +---[RSA 2048]----+
 |      o…Bo+    |
 |       o o Beo   |
 |        . . +.   |
 |       .   c o . |
 |        S   + o o|
 |       .     o o.|
 |              …|
 |               Eo|
 |               ..|
 +-----------------+

Polecenie to utworzy klucz rsa w podkatalogu .ssh w naszym katalogu domowym. Wklejamy nasz klucz do pliku authorized_keys, który musimy umieścić na serwerze backupowym:

cat .ssh/id_rsa_rfc.pub >> authorized_keys

Plik ten musimy skopiować na serwer do katalogu .ssh z uprawnieniami 0700 (rwx – – – – – – ), plik authorized_keys powinien mieć uprawnienia 0600 (rw – – – – – – – ).

Ostatnim krokiem będzie teraz przygotowanie katalogu dla naszych kopii zapasowych. Na nasze potrzeby będzie to katalog /backups/pliki, dodatkowo utwórzmy katalog np. do kopii baz mysql: /backups/mysql.

Inicjalizacja repozytorium

Inicjujemy nasze repozytorium poleceniem:

borg init --encryption=repokey ssh://user@server:23/backups/pliki
 Enter new passphrase: 
 Enter same passphrase again: 
 Do you want your passphrase to be displayed for verification? [yN]:

 IMPORTANT: you will need both KEY AND PASSPHRASE to access this repo!
 Use "borg key export" to export the key, optionally in printable format.
 Write down the passphrase. Store both at safe place(s).

Hasło możemy zostawić puste, aby zabezpieczyć sobie dostęp do kopii zapasowych w razie utraty danych na lokalnym komputerze powinniśmy wygenerować klucz repozytorium. Plik ten zapisujemy gdzieś w bezpiecznym miejscu.

borg key export ssh://user@server:23/backups/pliki ~/backup_key_pliki.txt

Analogicznie postępujemy z repozytorium dla baz danych, zamiast pliki wpisujemy po prostu mysql:

borg init --encryption=repokey ssh://user@server:23/backups/mysql
borg key export ssh://user@server:23/backups/mysql ~/backup_key_mysql.txt

W ten sposób jesteśmy przygotowani do tworzenia naszych kopii zapasowych. Pierwszy backup możemy uruchomić poleceniem:

borg create --stats --exclude-caches ssh://user@server:23/backups/pliki::2021-05-15-initial ~/katalog1 ~/katalog2

 Archive name: 2021-05-15-initial
 Archive fingerprint: afb2dff8f034faeeea8f27ce1a2bf6a01513f7111801072832a2d9549bf7e245
 Time (start): Mon, 2021-05-15 23:04:00
 Time (end):   Mon, 2021-05-15 23:04:01
 Duration: 0.66 seconds
 Number of files: 88
 Utilization of max. archive size: 0%
                    Original size      Compressed size    Deduplicated size
 This archive:              107.42 kB             59.48 kB             55.36 kB
 All archives:              107.42 kB             59.48 kB             55.36 kB
                    Unique chunks         Total chunks
 Chunk index:                      81                   90

Po zakończeniu wysyłania plików zobaczymy szczegółowe informacje operacji – między innymi nazwę archiwum, czas uruchomienia i zakończenia, rozmiar oryginalny, skompresowany oraz rozmiar danych deduplikowanych.

Skoro mamy już gotowe środowisko do tworzenia kopii zapasowych, warto zautomatyzować tworzenie tych kopii oraz utworzyć skrypty do montowania repozytorium z kopiami na naszym komputerze. Ale o tym w kolejnych częściach.

Mam nadzieję, że temat Was zainteresuje, bo do tego, że warto mieć dobre backupy nikogo przekonywać chyba nie potrzeba.


Strona domowa projektu Borg: https://www.borgbackup.org/
Dokumentacja: https://borgbackup.readthedocs.io/en/stable/

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Poprzedni post

Klawiatura Launch – Nowość od firmy System76

Następny post

Nowości SUSE z konferencji SUSECON 2021

Powiązane posty
Clonezilla live 2.6.5-21

Clonezilla live 2.6.5-21

10 marca wydano najnowszą wersję systemu Clonezilla – Clonezilla live 2.6.5-21. Jest to specjalistyczna dystrybucja Linuksa, która działa w trybie „Live”. Służy ona do wykonywania kopii systemu lub poszczególnych katalogów oraz ich późniejszego przywracania.

Więcej...

Limity deskryptora pliku i Dovecot (Debian)

Jeden z moich serwerów poczty osiągnął ostatnio maksymalny limit połączeń IMAP i byłem zmuszony zwiększyć wartość login_max_processes_count. Jednakże po restarcie usługi pojawił się poniższy błąd:

IMAP/POP3 mail server: dovecotWarning: fd limit 1024 is lower than what Dovecot can use under full load (more than 1512). Either grow the limit or change login_max_processes_count and max_mail_processes settings

Po dłuższym zastanowieniu doszedłem do wniosku, że mowa chodzi o limit deskryptora pliku.

Więcej...