Jak to zwykło się mawiać w świecie IT: ludzie dzielą się na te osobniki, które robią backup i te, co backup robić będą. Jakiś czas temu pochyliłem się nad zagadnieniem czy smartfon z Androidem bez Google Play Services ma sens. Poruszyłem tam problem tworzenia kopi zapasowej danych użytkownika zgromadzonych w telefonie. W tym podlinkowanym artykule zostało przestawione jak przy pomocy TWRP dokonać pełnego backupu całego systemu urządzenia i o ile pod względem technicznym takie podejście było jak najbardziej w pełni do zaakceptowania, to jednak to rozwiązanie miało dość istotną wadę, tj. na czas backup'u trzeba było wyłączyć smartfon. Parę dni temu natrafiłem na narzędzia OAndBackupX, które jest w stanie zrobić kopię zapasową wszystkich zainstalowanych w Androidzie aplikacji (oraz ich ustawień), wliczając w to nawet appki systemowe. OAndBackupX jest o tyle lepszym rozwiązaniem w stosunku do TWRP, że można przy jego pomocy robić kopię danych pojedynczych aplikacji, a nie od razu całego ROM'u, co nie tylko jest czasochłonne ale również zjada sporo miejsca na dysku komputera, czy gdzie ten backup zamierzamy przechowywać. Niestety OAndBackupX wymaga uprawnień root, zatem na stock'owym ROM'ie producenta naszego telefonu nie damy rady z tego narzędzia skorzystać. Jeśli jednak mamy alternatywny ROM na bazie AOSP/LineageOS, to przydałoby się rzucić okiem na ten kawałek oprogramowania, bo zdaje się ono być wielce użyteczne, zwłaszcza w przypadku osób mojego pokroju, czyli linux'iarzy, którzy o backup swoich danych chcą zatroszczyć się tylko i wyłącznie we własnym zakresie, zaprzęgając do pracy choćby Syncthing.

Gdy chodzi o bezpieczeństwo danych przechowywanych na nośnikach pamięci masowych, takich jak dyski twarde, to użytkownicy linux'a często piszą sobie skrypty shell'owe mające na celu przeprowadzić backup całego nośnika lub też jego konkretnych plików/katalogów. Zwykle zaprzęgany jest do pracy rsync , który bez problemu jest w stanie zsynchronizować zawartość dwóch folderów (źródłowego i docelowego) i po tym procesie wołany jest także tar mający na celu skompresować pliki backup'u, tak by zajmowały mniej miejsca. Nie mam nic do tego rozwiązania, bo sam też przez lata z niego korzystałem ale ma ono całą masę wad. Przede wszystkim, ten mechanizm nie bierze pod uwagę zmian w samych plikach, czyli tworzy kopię tego co mu się poda i w taki sposób mamy wiele paczek .tar.gz , które zajmują sporo miejsca. Kolejną sprawą jest brak zabezpieczenia przed nieuprawnionym dostępem do plików kopii zapasowej, np. przy pomocy szyfrowania. W ten sposób trzeba posiłkować się zewnętrznymi rozwiązaniami, np. pełne szyfrowanie dysku za sprawą LUKS/dm-crypt, co nie zawsze jest możliwe i też bardzo komplikuje cały proces tworzenia kopii zapasowej, zwłaszcza na zewnętrznych nośnikach czy zdalnych hostach w sieci. Ostatnio jednak trafiłem na narzędzie BorgBackup, które to dość znacznie upraszcza cały proces tworzenia backup'u plików na linux, a takie cechy jak szyfrowanie, kompresja i deduplikacja danych są w borg zaimplementowane standardowo. Postanowiłem zatem zmigrować z mojego skryptowego systemu tworzenia kopii zapasowych na rzecz borg'a i spisać przy okazji te użyteczniejsze informacje dotyczące posługiwania się tym narzędziem

W artykułach dotyczących przeprowadzania procesu root na smartfonach Neffos Y5 oraz Y5L był pokazany sposób na dokonanie backup'u całego flash'a tych urządzeń. Jeśli Android w naszym telefonie jest ukorzeniony albo chociaż mamy wgrany obraz TWRP na partycję /recovery/ , to jesteśmy w stanie przeprowadzać regularny backup wszystkich danych użytkownika z poziomu trybu recovery. Proces takiego backup'u będzie się nieco różnił w stosunku do tego opisywanego w wyżej podlinkowanych artykułach. W tym przypadku nie będziemy robić kopii binarnej, a jedynie zgramy sobie wszystkie pliki znajdujące się na partycji /data/ . W tym artykule zostanie pokazany sposób na przeprowadzanie procesu kopii zapasowej w smartfonie Neffos Y5. Niemniej jednak, taki regularny backup można przeprowadzać praktycznie w każdym smartfonie posiadającym recovery z TWRP.

W dzisiejszych czasach systemy operacyjne są bardziej odporne na błędy niż to miało miejsce kilka czy kilkanaście lat temu. Bardzo ciężko jest się zatem odnaleźć w sytuacji, gdzie nasz linux odmawia współpracy i nie chce się w ogóle uruchomić. Niemniej jednak, jeśli chodzi o samą kwestię naprawiania szkód po ewentualnej awarii systemu, to, jakby nie patrzeć, zajmuje ona nasz cenny czas. Oczywiście takie błędy sprawiają, że mamy szansę nieco zgłębić strukturę używanego systemu operacyjnego ale też pojawiają się one w najmniej oczekiwanym momencie. W takiej sytuacji nie ma mowy byśmy siedzieli paręnaście minut i zastanawiali się nad tym dlaczego coś nie działa jak należy. Jest kilka mechanizmów bezpieczeństwa, które mogą nam nieco czasu zaoszczędzić. W tym wpisie omówimy sobie zagadnienia związane z LVM snapshot, czyli migawką systemu, którą możemy wykonać praktycznie natychmiast i w razie problemów przywrócić system do stanu sprzed wprowadzenia w nim zmian.