Jak wykonać kopię zapasową routera OpenWrt, gdy wbudowane narzędzia zawodzą

W przeszłości korzystałem z metody aktualizacji urządzeń OpenWrt z opcją przywrócenia wszystkich zainstalowanych pakietów i ich konfiguracji, bez konieczności spędzania godzin na ponownym konfigurowaniu i testowaniu wszystkiego.

Ta metoda używa prostego skryptu uruchamianego w terminalu do wygenerowania listy zainstalowanych pakietów, a następnie interfejsu WWW do utworzenia pliku kopii zapasowej, który służy do przywrócenia wszystkiego.

Dopóki plik kopii zapasowej jest poprawnie wygenerowany, proces przywracania działa dobrze, ale problem pojawia się, gdy tak nie jest!

Na kilku routerach z OpenWrt (24.10.x), z którymi pracowałem w ostatnich tygodniach, napotkałem dziwny problem, który zmusił mnie do przemyślenia sposobu generowania pliku kopii zapasowej, aby później wykorzystać go do przywrócenia wszystkich pakietów i ustawień po aktualizacji OpenWrt do najnowszej wersji.

Odkryłem ten problem w praktyce, kiedy chciałem rozpakować kopię zapasową, aby odzyskać pewną konfigurację z poszczególnych plików. Zauważyłem, że kopia zapasowa nie została poprawnie rozpakowana.

Generowanie archiwum (backup) – LuCI

Zazwyczaj, aby wygenerować plik kopii zapasowej swojej konfiguracji, należy przejść do:

• System > Backup / Flash Firmware

Stamtąd wystarczy kliknąć Generate archive, aby uzyskać swoją kopię zapasową.

Jeżeli chcesz dołączyć dodatkowy folder do archiwum, kliknij zakładkę Configuration, gdzie możesz wskazać dodatkową lokalizację do uwzględnienia, wpisując każdą ścieżkę w osobnym wierszu.

Moja obecna zawartość wygląda następująco:

## This file contains files and directories that should
## be preserved during an upgrade.

# /etc/example.conf
# /etc/openvpn/
/etc/ssl/
/etc/cloudflared/
/etc/sysctl.d/
/etc/init.d/
/etc/config/
/root/
Copy

Można to znaleźć w pliku /etc/sysupgrade.conf.

Zmodyfikowane pliki w /etc/config/ oraz niektóre inne konfiguracje są automatycznie zachowywane przez OpenWrt, więc nie trzeba ich jawnie uwzględniać.

Testowałem liczne warianty generowania pliku kopii zapasowej, z dodatkowymi folderami i bez nich. Za każdym razem, na którymś etapie, kopia stawała się uszkodzona.

Głównym problemem jest to, że problem jest niepowtarzalny (nie da się go odtworzyć, wykonując te same kroki).

Możesz udokumentować wszystkie kroki aż do momentu napotkania problemu, wykonać reset fabryczny routera i je powtórzyć, a jednak problem może już się nie pojawić — lub wystąpić znacznie wcześniej.

Przyczyna pozostaje nieznana.

Uszkodzone archiwum (backup) – LuCI

Wracając do wygenerowanego archiwum kopii zapasowej.

Zazwyczaj, po naciśnięciu przycisku Generate archive, przeglądarka automatycznie pobiera plik:

• backup-OpenWrt-2025-09-01.tar.gz

Po rozpakowaniu tego pliku dowolnym dostępnym narzędziem (takim jak 7Zip w Windows lub Keka w macOS), powinieneś zobaczyć folder zawierający /etc i /root.

Każdy z tych folderów będzie zawierał pliki tekstowe, które można otworzyć dowolnym programem, aby uzyskać dostęp do ustawień.

Problem pojawia się, gdy próbujesz rozpakować plik i kończysz z pojedynczym plikiem TAR zamiast z folderami i plikami. Kolejne próby rozpakowania tego pliku TAR kończą się błędem.

tar: Error opening archive: Unrecognised archive format
Copy

Kiedy uruchamiam file backup-OpenWrt-2025-09-01.tar.gz, system rozpoznaje go jako prawidłowe archiwum:

backup-OpenWrt-2025-09-01.tar.gz: gzip compressed data, from Unix, original size modulo 2^32 895035
Copy

Niektórzy zasugerowali, że przyczyną może być używana przeglądarka internetowa lub system operacyjny. Próbowałem na różnych komputerach i przeglądarkach — z tym samym rezultatem.

Co ciekawe, plik TAR można otworzyć w VS Code przy użyciu Text Preview, gdzie pomiędzy dużą ilością śmieciowych danych można zobaczyć zawartość poszczególnych plików. W najgorszym przypadku można stamtąd odzyskać potrzebne dane. Wygląda na to, że pliki i struktura folderów zostają uszkodzone podczas rozpakowywania.

Generowanie archiwum (backup) – terminal

Spróbowałem wygenerować kopię bezpośrednio na routerze, aby wyeliminować wpływ przeglądarki internetowej lub systemu operacyjnego.

Skorzystałem z proponowanej metody:

# Generate backup
umask go=
sysupgrade -b /tmp/backup-${HOSTNAME}-$(date +%F).tar.gz
ls /tmp/backup-*.tar.gz

Uszkodzone archiwum (backup) – terminal

Po wygenerowaniu pliku spróbowałem go rozpakować w folderze /tmp na routerze:

tar -zxvf backup-OpenWrt-2025-09-01.tar.gz

i otrzymałem

tar: invalid tar magic
Copy

Ponieważ niektóre instalacje OpenWrt nie zawierają najnowszej lub pełnej wersji polecenia TAR, zainstalowałem je:

opkg update
opkg install tar

Powtarzając moją komendę rozpakowania tar -zxvf, otrzymuję:

tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
Copy

Analiza uszkodzenia z użyciem AI

Kiedy skończyły mi się opcje i nie mogłem ustalić konkretnego pakietu powodującego problem, użyłem AI do analizy wyodrębnionego pliku TAR, aby poznać jego sugestie:

Na podstawie dostarczonego podsumowania i fragmentu, plik tar (backup-OpenWrt-2025-08-20.tar) zawiera w większości poprawne pliki konfiguracyjne i inicjalizacyjne OpenWrt, ale widać oznaki uszkodzeń:

• Śmieci binarne i nieprawidłowe bajty null: Wiele plików ma końcowe lub osadzone bajty null (\x00) oraz dane binarne, co nie jest normalne dla plików konfiguracyjnych w formacie tekstowym.
• Granice plików i dopełnienia: Niektóre pliki mają nadmierne wypełnienie lub nie są prawidłowo zakończone, co może powodować problemy przy rozpakowywaniu tar.
• Niezgodność rozmiarów plików: Nagłówki tar określają rozmiary plików, ale rzeczywista zawartość może się nie zgadzać, co powoduje błędy przy rozpakowywaniu.

Najbardziej prawdopodobna przyczyna błędu rozpakowywania:

• Uszkodzenie prawdopodobnie wynika z niepoprawnych granic plików, nadmiernego wypełnienia null lub obciętych plików, szczególnie w plikach binarnych, takich jak .tdb czy pliki kluczy.
• Jeśli pojawiają się błędy typu Unexpected EOF lub tar: Skipping to next header, zwykle oznacza to, że strumień tar został przerwany lub deklarowany rozmiar pliku nie zgadza się z rzeczywistą zawartością.

Alternatywny sposób generowania archiwum (backup)

Podczas przeszukiwania forum OpenWrt i innych stron, natknąłem się na różne metody generowania kopii zapasowej bezpośrednio z routera.

sysupgrade -l | tar -czf backup.tar.gz -T -

Na tej podstawie stworzyłem swój plik, który generuje poprawne archiwum z moimi plikami kopii zapasowej, możliwe do prawidłowego rozpakowania, mimo że oficjalna metoda tworzenia kopii zapasowej (przez przeglądarkę lub oficjalne polecenie w terminalu) zwracała uszkodzony plik.

Stworzyłem plik gen_backup w folderze /root i nadałem mu prawa do wykonania przy pomocy chmod +x gen_backup. Plik zawierał:

# Generate backup
umask go=
sysupgrade -l -v | tar -czf /tmp/backup-${HOSTNAME}-$(date +%F).tar.gz -T -
ls /tmp/backup-*.tar.gz

Po poprawnym uruchomieniu komendy w folderze /tmp otrzymuję plik kopii zapasowej backup-OpenWrt-2025-09-01.tar.gz.

Teraz muszę pobrać ten plik i zapisać go lokalnie.

Kopiowanie wygenerowanego archiwum (backup) – SFTP

Aby skopiować plik z routera, muszę zainstalować serwer FTP.

opkg update
opkg install openssh-sftp-server

Teraz, za pomocą wybranego klienta FTP (ja używam CyberDuck na macOS), należy nawiązać połączenie SFTP (na porcie SSH, domyślnie 22), logując się danymi roota.

Po przejściu do folderu /tmp można łatwo przeciągnąć plik na komputer.

Lokalnie, dwukrotne kliknięcie w pobrany plik spowoduje jego prawidłowe rozpakowanie, prezentując foldery z plikami konfiguracyjnymi.

Jeśli plik rozpakowuje się poprawnie w ten sposób, przywracanie ustawień z zainstalowanymi pakietami, jak opisano, zadziała prawidłowo.

Nawet jeśli zmienisz urządzenie i nie możesz przywrócić systemu metodą opisaną wyżej, poprzez lokalne rozpakowanie i przejrzenie każdego pliku konfiguracyjnego możesz szybko przygotować nowe urządzenie do działania jak poprzednie.

Problem jest bardzo intrygujący i trudny do zrozumienia.

Próbuję zaangażować się w dyskusję na OpenWrt Forum post #235434, aby znaleźć rozwiązanie, jednak jak dotąd nic nie wskazuje na przyczynę ani możliwe długoterminowe rozwiązanie. Jeśli problemu nie da się powtórzyć, trudno znaleźć źródło.

Tymczasem mam działające rozwiązanie tworzenia kopii zapasowej, którego muszę się trzymać.

Pozdrawiam.