rozwiązanie do tworzenia kopii zapasowych z obsługą btrfs

14

W tym miesiącu btrfs osiągnął produkcję w Oracle EL 14 (wraz z działającym fsck i scrubbingiem z Linuksa 3.2). Myślałem o przeprojektowaniu mojego obecnego rozwiązania do tworzenia kopii zapasowych, aby go wykorzystać. Zauważ, że myślę o zrobieniu tego dla niewielkich ilości danych, mniejszych niż 10 TB, co jest dość statyczne (mniej niż 1% zmieniane codziennie). W skrócie rozwiązanie do tworzenia kopii zapasowych SMB / SOHO.

Co powinna zrobić kopia zapasowa:

wykonaj migawkę LVM ext [234] / XFS / JFS na serwerze produkcyjnym
rsync/ przenieś zmienione dane do btrfs na serwerze backupu
migawka systemu plików btrfs
upuść stare migawki, gdy kończy się wolne miejsce

Plusy:

Wszystkie pliki są łatwo dostępne, nie wymaga dekompresji ani montażu w pętli
Wcześniejsze migawki są również łatwo dostępne ...
... więc mogę udostępnić je jako udziały Samba tylko do odczytu (z obsługą kopiowania w tle)
Migawki zajmują minimalną ilość miejsca dzięki kopiowaniu przy zapisie (migawka bez zmian zajmuje dosłownie kilka KiB na dysku)
Wysoka spójność kopii zapasowych: sumy kontrolne plików, czyszczenie wszystkich danych i wbudowana redundancja

Pytania:

Czy istnieje jakieś rozwiązanie do tworzenia kopii zapasowych (w postaci Bacula, BackupPC itp.), Które jest lub może być łatwo wykonane, wiedząc o systemie plików kopiowania przy zapisie?
Czy będę musiał użyć rsyncrozwiązania domowego ?
Co robią ludzie z urządzeniami ZFS dedykowanymi do tworzenia kopii zapasowych, aby wykonać kopię zapasową swoich komputerów z systemem Linux?

— Hubert Kario
źródło

Nie widzę cons! Jednym z nich byłoby to, że migawki Btrfs są równoważne tylko przyrostowym kopiom zapasowym (brak fizycznej kopii na kopię pliku na dysku). Co może mieć znaczenie w przypadku problemów z powierzchnią dysku. Pamiętaj, że możesz wymusić jedną duplikację dzięki natywnej obsłudze RAID1 zawartej w Btrfs.

— vaab

1

@vaab: to pro- więcej niż dwie kopie nie są tak naprawdę potrzebne, jeśli masz sumy kontrolne i aktywnie szorujesz FS, trzy prawdopodobnie będą miały obsługę RAID6. Jak powiedziałem, jest to konfiguracja dedykowanego systemu tworzenia kopii zapasowych, a nie „kopii zapasowych” kopii w FS na pojedynczym komputerze. To byłoby „RAID nie jest kopią zapasową”, a „migawki nie są kopią zapasową”. cp -ai rsyncsą za to ...

— Hubert Kario

Zastanawiam się także nad utworzeniem kopii zapasowej na btrfs, ale właśnie myślałem rsync -a --delete /home/user /mnt/butterfs/backups/ && snapper create- oprócz tworzenia migawki po utworzeniu kopii zapasowej, co masz na myśli przez opcję COW?

— młot

1

@unhammer: używanie rsyncbez --inplacedostaniesz wiele kopii tych samych danych w zdalnym systemie plików. (rsync normalnie kopiuje dane do tymczasowego ukrytego pliku, a następnie przenosi go nad starym pliku w systemie plików kopiowanie przy zapisie masz dwie kopie danych niezmienionych ten sposób)

— Hubert Kario

5

W zeszłym tygodniu przeprowadziłem obszerne poszukiwania czegoś podobnego. Nie znalazłem rozwiązania dla wykonania wszystkich 4 kroków. Istnieje wiele blogów od użytkowników domowych, którzy wypróbowują kopie zapasowe typu „ rsync to btrfs ”, a wszystkie główne strony wiki Btrfs opisują sposób wykonywania migawek Btrfs.

Jest też sporo osób, które próbują różnych sposobów obracania migawek Btrfs . Jednak jesteś pierwszą osobą, którą widziałem, która chce obracać migawki na podstawie miejsca na dysku. Sam gram z btrfs-snap, który tworzy zestaw migawek co godzinę, co tydzień i co miesiąc, i jest ładny i prosty.

Projekt Dirvish wydaje się spełniać wiele twoich wymagań. Niektórzy programiści próbują zintegrować Dirvish z Btrfs . Jednak projekt Dirvish wydaje się nieco wstrzymane .

W tym momencie wyprzedzasz zakręt.

— Stefan Lasiewski
źródło

Chcę tylko rozwiązania do tworzenia kopii zapasowych tak bezbolesnego jak BackupPC: gdy miejsce na dysku jest mało, to po prostu usuwa stare dane (stare migawki). Chociaż obawiałem się, że wyprzedzam zakręt, nie jest tak, że ZFS nie był z nami od kilku lat ...

— Hubert Kario

3

Według Aviego Millera (jego przemówienie podczas LinuxConf.AU) trwają prace nad wysyłaniem / odbieraniem btrfs. Będzie szybszy niż rsync, ponieważ nie musi przeglądać katalogów, aby znaleźć zmiany w plikach. Nie wiem jednak, czy jest jeszcze przewidywana data wydania.

Istnieje jednak narzędzie wbudowane w btrfs-progs, które wyświetla listę wszystkich plików, które zmieniły się między migawkami / etc .. subvolume btrfs find-new

— Borring
źródło

2

Chcę wykonać kopię zapasową na btrfs, a nie z ...

— Hubert Kario

2

Pracuję na systemie kopii zapasowych systemu operacyjnego podobnym do BackupPC. Myślałem o tym. To, co powstrzymało mnie przed faktycznym wdrożeniem, to to, że nie można na stałe połączyć między podwoluminami. Można również tworzyć migawki podwoluminów -> Jedna objętość cząstkowa na klienta kopii zapasowej. Dlatego funkcja deduplikacji na poziomie plików nie może współistnieć z tym podejściem. A deduplikacja na poziomie plików zwykle oszczędza dużo miejsca. Czy chcesz wykonać kopię zapasową tylko jednego serwera?

Jeśli btrfs miał deduplikację na poziomie bloku, problemu tego można prawdopodobnie uniknąć, ale zwykle jest to również niewyobrażalnie powolne ...

Takie podejście wymagałoby oczywiście ścisłej integracji z jednym systemem plików (btrfs), więc powinna to być funkcja opcjonalna.

Pytam, bo myślę o dodaniu takiej cechy krowy, ale nie wiem, czy powinienem z powodu wymienionych wyżej wad.

Edycja: UrBackup obsługuje kopie zapasowe, jak opisano w pytaniu teraz z jądrem Linux> = 3.6 (z obsługą reflink między woluminami). Zobacz, jak to skonfigurować.

— UrOni
źródło

1

kopia odsyłacza między woluminami (pół-twardy link wykonany przez cp --reflink) jest już zaimplementowana lub zostanie wdrożona w najbliższej przyszłości. Online duplikacja w FS jest albo powolna (mniej), albo wymaga ogromnej ilości pamięci RAM (ZFS), więc w zależności od tego byłaby naprawdę zła funkcja w oprogramowaniu do tworzenia kopii zapasowych. Tak czy inaczej, oprogramowanie do tworzenia kopii zapasowych zorientowane na btrfs będzie miało dużą publiczność, w końcu ma to być następny ext3.

— Hubert Kario

Jeszcze jedno: możesz obejść ten problem, utrzymując wszystkie serwery w jednej podobjętości - możesz ponownie powiązać kopię między nimi (aby deduplikować), zachowując jednocześnie możliwość wykonywania migawek. Musisz po prostu wykonać migawkę po deduplikacji, nadal możesz wykonać migawkę po utworzeniu kopii zapasowej tylko jednego serwera! Kopie zapasowe nie zajmują więcej miejsca, jeśli wykonujesz je pojedynczo. Alternatywnie możesz wykonać kopię zapasową wszystkich serwerów, dedupe i dopiero wtedy wykonać migawkę. W ten sposób możesz wykonać kopię zapasową kilku serwerów jednocześnie.

— Hubert Kario

Masz rację. Nie myślałem o tym. Dla wygody możesz następnie utworzyć dowiązanie symboliczne do odpowiednich migawek w innym woluminie. Widziałem także łatkę do linku twardego o dużej objętości (lub --reflink), ale nie wyglądało to tak, jakby to zrobiło / lub spowoduje przejście do głównej linii. Naprawdę się temu przyjrzę! Teraz prawdopodobnie wykonujesz kopie zapasowe za pośrednictwem ssh. Mój projekt specjalizuje się w sieciach lokalnych ... (automatyczne wykrywanie i tak dalej)

— UrOni

Tak, łatka jest żywa i działa, niestety nie w głównej linii, nie wiem dlaczego. Staram się na to wkurzać Chrisa Masona. Jeśli chodzi o twój projekt, napisz do mnie, chętnie przetestuję go w wersji beta (jeśli czas na to pozwala). Brzmi interesująco.

— Hubert Kario

Wreszcie łatka wylądowała w głównym jądrze Linuksa 3.6. Dzięki reflink między urządzeniami nie było tak dużo pracy. Napisałem tutaj o tym: urbackup.org/blog/?p=83 Kod znajduje się w gałęzi „next” w repozytorium git. Obecnie testuję to.

— UrOni

1

Strona wiki btrfs „ Use Cases ” wymienia niektóre narzędzia: SnapBtr , Snapper, btrfs-time-machine, UrBackup.

Istnieje propozycja wbudowanego narzędzia o nazwie autosnap :

Korzystając z funkcji autosnap, możesz skonfigurować btrfs do robienia migawek regularnych lub opartych na zdarzeniach i dalszego automatycznego zarządzania migawkami.

Autosnap nie polega tylko na robieniu migawki, ale także na zarządzaniu utworzonymi migawkami, od tej pory można skonfigurować autosnap do usuwania migawek w oparciu o przestrzeń używaną przez system plików.

Jednak od października 2013 r. Wiki stwierdza, że „funkcja autosnap nie jest obecnie uwzględniona w poprzedniej wersji btrfs”.

— ignis
źródło

1

Miałem podobne frustracje, więc ostatecznie stworzyłem kilka skryptów, które nazywam snazzer . Razem oferują migawkę, przycinanie, pomiar i transport przez ssh (ale na dzień dzisiejszy mogą również wysyłać / odbierać do / z lokalnych systemów plików). Pomiary są tylko raportami podpisów sha512sum i PGP ścieżek migawek. Nie jest jeszcze całkiem gotowy do wydania, ale chciałbym usłyszeć opinie, jeśli ktoś ma czas na jego przejrzenie na tym wczesnym etapie.

W tym momencie tylko CLI, ale poświęciłem trochę czasu, aby ułatwić korzystanie z niego w systemach z wieloma podobjętościami btrfs - zazwyczaj mam osobne podobjętości dla /var/cache , /homeitp, które mogą być potrzebne, aby wykluczyć z snapshotting lub mają więcej / mniej agresywne harmonogramy przycinania.

Obawiam się, że algorytm przycinania podejmuje wyłącznie decyzje dotyczące obecności zestawu migawek i ich dat, nic nie stoi na przeszkodzie, aby utrzymać się do czasu spełnienia ograniczenia użycia dysku - które usuniesz jako pierwsze? Najpierw zmniejszyć liczbę godzin lub dziennych? Być może upuść najstarszy, np. roczniki? Różne wdrożenia będą miały różne priorytety; i nie wiem, czy jest to jedyna warstwa zapasowa (w takim przypadku nie należy upuszczać najstarszych kopii zapasowych w przypadku zobowiązań prawnych / ubezpieczeniowych), czy tylko pośrednia (w którym to przypadku prawdopodobnie masz te archiwa w bezpiecznym miejscu gdzie indziej).

W pewnym momencie dodam obsługę ZFS i / lub interoperacyjność; jest napisany głównie w powłoce posix-ish i perl ze względu na silne pragnienie „zerowych” zależności w tej chwili, mam nadzieję, że w pewnym momencie utrzymam równolegle czystszą alternatywną implementację Pythona.

— csirac2
źródło

chyba że twój FS ma bardzo duże i często się zmienia, nie ma bardzo małej różnicy między utrzymywaniem migawki sprzed miesiąca, a tylko 1 dziennie z ostatniego tygodnia w porównaniu do jednego dziennie przez cały miesiąc - btrfs będzie musiał zapisać różnicę między obecny stan i ten sprzed miesiąca - i tak trzymam tylko dzienniki, ale ponieważ są skompresowane i zróżnicowane, mogę je łatwo utrzymać przez pół roku wstecz - a następnie upuszczając najstarsze gwarancje, aby zwolnić przynajmniej trochę miejsca

— Hubert Kario

Cóż, mam do dyspozycji trywialną liczbę maszyn wirtualnych - niektóre z dużymi plikami przejściowymi (tj. Migawki z unikalnymi rozmiarami), które, jak sugerujesz, mogą skorzystać z przycinania pośrednich migawek. Tak więc chociaż prawdą jest, że przycinanie półproduktów nie zwalnia tyle miejsca, co upuszczenie najstarszego, to co mogę powiedzieć ... utrzymanie tylko minimalnej liczby migawek i robienie tego z systemem plików COW, takim jak btrfs, wydaje się być tak samo wydajne jak robi się, ale zdaję sobie sprawę, że wybranie odpowiedniego rozwiązania jest coś więcej :)

— csirac2

@ csirac2 czy utrzymujesz snazzer? Szukam tego rodzaju rozwiązania. Interesuje mnie snazzer, jeśli jest aktywnie utrzymywany. GitHub nie wydaje się pokazywać ostatniej aktywności ...

— MountainX

@MountainX Kiedy nie otrzymałem wiele wstępnych opinii na temat snazzera, trochę straciłem entuzjazm. Kiedy zacząłem go pisać, tak naprawdę był tylko snapper OpenSUSE i garść skryptów powłoki / pytona, które automatyzowały btrfs. Zanim zacząłem dzielić się tym ze światem, pojawiło się wiele innych opcji i powiedziałbym, że btrbk wydaje się mieć duży rozpęd (chociaż niepokoiło mnie brak automatycznego testowania [może teraz naprawiony?]). Gdybym musiał zrobić to wszystko jeszcze raz, prawdopodobnie współpracowałbym z sanoidalnym autorem, aby dodać kompatybilność z btrfs. Chciałbym usłyszeć twoje myśli.

— csirac2