Udostępnianie plików odtworzonych z backupu - Bakdrop

W trakcie wielu lat pracy z systemami backupu w różnych środowiskach wielokrotnie spotykałem się z dosyć specyficznym, choć na pozór prozaicznym problemem: w jaki spobób odtworzyć dane na hosty, na których nie mamy agenta backupu, poświadczeń czy otwartego ruchu sieciowego? W jaki sposób bezpiecznie je udostępnić użytkownikom końcowym? Postanowiłem rozprawić się z tym problemem raz na zawsze, tworząc aplikację Bakdrop.

Właściwie na czym polega problem z odtwarzaniem plików?

Na początek wyjaśnijmy, jak zwykle wygląda temat odtwarzania danych w systemach kopii zapasowych. Z reguły odtwarza się całe maszyny wirtualne lub ich dyski (z backupu snapshotowego) lub pojedyncze pliki (w przypadku backupu agentowego). W większości systemów możliwe jest również odtworzenie danych z backupu snapshotowego w postaci plików z wnętrza maszyny wirtualnej, czyli tak samo jak w przypadku backupu agentowego.

W przypadku maszyn z zainstalowanym agentem systemu backupu sytuacja jest jasna: po prostu odtwarzamy dane w dowolne miejsce na hoście. Ale co w przypadku maszyn, które takiego agenta nie mają?

W większości środowisk, w których pracowałem backup odbywa się snapshotowo, czyli zabezpieczane są całe maszyny wirtualne. Nie ma więc powodu instalować na nich agenta. W większości przypadków restore sprowadza się do odtworzenia całej maszyny wirtualnej lub pojedynczego dysku, który zostaje dołączony do istniejącej VM-ki.

Czasami jednak jest potrzeba odtworzenia jedynie konkretnych plików lub katalogów, a nie całej maszyny. Aby jednak wylądowały na docelowym hoście, to system backupu musi mieć dostęp do jego OS-u, czyli mieć tam agenta. Niektóre systemy, jak np. Commvault, pozwalają również odzyskać pliki na maszynę bezagentowo - ma to jednak wiele ograniczeń (tylko VMware, pliki mniejsze niż 10 GB, konieczność podawania poświadczeń).

Ktoś może zapytać - skoro tak, to jaki problem zainstalować agenta na wszystkich maszynach wirtualnych tylko dla celów ewentualnego odtwarzania plików? Np. Commvault pozwala na instalację agentów w trybie restore only - nie zużywają wtedy licencji. Jest to jak najbardziej prawidłowe podejście, ale niepozbawione wad. Po pierwsze, z różnych względów nie wszyscy chcą takiego agenta na swoich serwerach. Po drugie, w domkniętych sieciowo środowiskach konieczne jest otwarcie ruchu z/do każdej maszyny. Po trzecie, kwestia skali. W małym środowisku kilkunastu maszyn nie będzie to problem, ale kiedy maszyn jest kilkaset lub kilka tysięcy, nie będzie to ani proste, ani wygodne do zarządzania.

Co więc zazwyczaj robi się w sytuacji, kiedy nie mamy agenta na maszynie? Odtwarza “gdzieś na boku”, a potem “jakoś” udostępnia docelowemu użytkownikowi.

No i właśnie tutaj jest clue problemu. No bo co to znaczy “na boku”? Z doświadczenia wiem, że zazwyczaj jest to sam serwer backupu lub inny host, na który dane wrzuca się “na chwilę” i potem kopiuje przez SMB, NFS, SCP czy jakikolwiek inny sposób.

Jest to jednak - mówiąc delikatnie - bardzo niedoskonałe podejście. Szczególnie złym pomysłem jest używanie jako stage’u jakiejkolwiek maszyny infrastruktury backupu (serwer główny, proxy, media agenty). Infrastruktura backupu powinna być maksymalnie odseparowana sieciowo od całej reszty. Nie powinna więc móc nic wysyłać, ani tym bardziej - udostępniać czegokolwiek innym hostom.

Okej, aby tego uniknąć, możemy utworzyć dedykowanego hosta, na który odtworzymy dane i z niego będziemy je udostępniać użytkownikom końcowym. Tylko jak? Osobiście próbowałem z SMB. Było to jednak bardzo problematyczne, ponieważ z oczywistych względów nie mógł to być zasób bez uwierzytelnienia. Zrobiłem kilka share’ów, następnie wysyłałem dostępy i hasła w razie potrzeby. Wypadało jednak zmieniać te hasła za każdym razem, aby móc wykorzystać share’y ponownie. Trzeba było również pamiętać o kasowaniu danych, no i nie każdy użytkownik radził sobie z łączeniem się do zasobu SMB. Administracyjny koszmar.

Do tego dochodzi jeszcze jeden problem - leżące tygodniami lub miesiącami zapomniane pliki. W końcu to ty, jako admin backupów musisz zadbać o to, aby były usunięte natychmiast po skopiowaniu ich przez docelowego użytkownika. Nietrudno wyobrazić sobie sytuację, w której ktoś nie dał znać, że można już usunąć pliki z zasobu, a ty o nich zapomniałeś. Taka okoliczność może być niepożądana choćby z punktu widzenia regulacji prawnych.

Pomyślałem, że najlepszym rozwiązaniem byłoby po prostu udostępnienie jednorazowego linka do pobrania plików, coś jak np. w weTrasnfer, tylko hostowane samodzielnie. Zacząłem szukać i natrafiłem m.in. na rozwiązania takie jak PicoShare, GoKapi, czy FileBrowser. Wiele z nich to na prawdę świetne projekty, jednak ostatecznie nie do końca nadawały się do planowanego przeze mnie zastosowania - były albo overkillem, albo nie wykrywały samodzielnie plików w danym katalogu (tylko przesyłane przez interfejs), nie miały też możliwości usunięcia pliku po udostępnieniu. Dlatego zdecydowałem, że stworzę taką aplikację samodzielnie.

Bakdrop - aplikacja do udostępniania odtworzonych danych

Założenia aplikacji były dość jasne:

• Możliwe prosta forma, minimalistyczny interfejs i tylko niezbędne funkcje,
• Interfejs admina umożliwiający tworzenie i usuwanie linków oraz usuwanie danych,
• Link w formie losowego ciągu znaków,
• Automatyczne odczytywanie plików z określonej lokalizacji na serwerze,
• Możliwość ustawienia automatycznego usunięcia udostępnionego pliku po pobraniu,
• Obsługa dowolnie dużych plików oraz automatyczne zipowanie folderów przy pobieraniu,
• Możliwość pobierania przez bezpośredni link ważna szczególnie w serwerach bez środowiska graficznego.

Z racji tego, że mam pewne doświadczenie w PHP, to właśnie w tym języku tworzona jest aplikacja. Do tego prosta baza SQLlite do przechowywania konfiguracji i danych o linkach.

Aktualnie (końcówka maja 2026) aplikacja jest już stabilna i działa bezproblemowo, pozostają ostatnie szlify, testy, dokumentacja i niebawem wydam pierwszy oficjalny release. Jeśli masz ochotę przetestować ją już teraz, możesz pobrać ją z Githuba, na którym znajdziesz również instrukcję instalacji.

Jak zbudowany jest Bakdrop

Jeśli jesteś ciekawy technicznych szczegółów, poniżej opisana jest struktura aplikacji z opisem najważniejszych plików.

├── api.php            // główne funkcje aplikacji
├── assets
│   ├── logo.png
│   └── style.css
├── auth.php           // uwierzytelnienie użytkownika
├── composer.json      // plik do pobrania biblioteki zipstream
├── config.php         // plik konfiguracyjny do uzupełnienia
├── db.php             // funkcje obsługi bazy danych
├── download.php       // pobieranie plików
├── helpers.php        // różne funkcje pomocnicze używane w innych skryptach
├── index.php          // panel admina
├── lang               // pliki tłumaczenia
│   ├── en.json
│   └── pl.json
├── setup.php           // kreator pierwszej konfiguracji
├── share.php           // obsługa linka udostępniania
├── vendor
└── views               // wydzielone widoki HTML
    ├── auth.view.php
    ├── index.view.php
    ├── setup.view.php
    └── share.view.php

Jak widać, nie jest przesadnie skomplikowana. Część kodu jest wydzielona dla przejrzystości - wszystkie powtarzające się funkcje wylądowały w helpers, a HTML został wyodrębiony widoków, aby łatwiej było go edytować. Wprowadziłem również obsługę języków - obsłużenie nowego języka sprowadza się do utworzenia nowego jsona i dodaniu jego obsługi w kodzie edytując jeden wiersz.

Wymagania i instalacja

Do działania aplikacji wystarczy serwer webowy (Apache, nginx), PHP w wersji 8.3+ i Composer (potrzebny do instalacji biblioteki ZipStream).

Możliwa jest również instalacja w postaci Dockera, wtedy wystarczy Docker + Docker Compose. W przypadku Dockera należy również nadać odpowiednie uprawnienia dla grupy www-data do katalogu, w którym przechowywane będą pliki do udostępnienia.

Więcej szczegółów na temat instalacji i konfiguracji znajdziesz na Githubie projektu.

Co do samego serwera Bakdropa w infrastrukturze, musi być na nim oczywiście zainstalowany nasz agent backupu oraz w razie potrzeby otwarte odpowiednie porty sieciowe (przychodzący 443/TCP ze wszystkich endpointów - aplikacja dostępna jest po HTTPS, oraz porty odpowiednie dla danego systemu backupu).

Ogólny workflow odtwarzania danych z Bakdrop

Najpierw admin odtwarza dane na serwer Bakdropa do naszego katalogu głównego aplikacji. Następnie loguje się do panelu admina i klika “Udostępnij”. W oknie udostępniania może zdecydować, czy ustawić wygaśnięcie linku, zabezpieczenie hasłem i usuwanie pliku po pobraniu. Po utworzeniu linku przekazuje go użytkownikowi końcowemu. Ten po prostu otwiera go w przeglądarce, wpisuje opcjonalne hasło i pobiera plik (lub folder - wtedy automatycznie zostanie pobrany jako zip). W przypadku, kiedy użytkownik nie ma dostępu do przeglądarki, na przykład w serwerach bez środowiska graficznego, może pobrać plik korzystając z linka bezpośredniego i komend typu wget lub curl. Poniższy schemat wyjaśnia jakie jest ogólne założenie.

Takie podejście moim zdaniem jest optymalne pod kątem bezpieczeństwa - użytkownicy sami pobierają swoje pliki, ich hosty nie wchodzą w żadną interakcję z systemem backupu, pliki istnieją w stage’owej lokalizacji tylko przez chwilę - czyli do momentu pobrania.

Interfejs

Założeniem interfejsu admina była maksymalna prostota i intuicyjność. W pierwszej sekcji wyświetlana jest lista plików istniejących w skonfigurowanym katalogu. Niżej widoczna jest lista aktywnych linków udostępniania. Poniżej zrzuty ekranu prezentujące aplikację.

Ekran udostępniania pliku z dostępnymi opcjami wygaśnięcia, usuwania i hasła:

Ekran do kopiowania linków. Dostępny jest zarówno link do strony pobierania (z opcjonalnym hasłem dostępu) lub link bezpośredni, który od razu powoduje pobranie pliku. Dodatkowo niżej wyświetlają się gotowe do skopiowania komendy curl i wget do wykorzystania w terminalu i wszędzie tam, gdzie nie ma dostępnego środowiska graficznego. Widoczne dodatkowe parametry -JO w curlu i –content-disposition w przypadku wget służą pobraniu oryginalnej nazwy pliku (bez nich pobrane pliki miałyby nazwę hasha z URL).

Tak wygląda otwarty przez użytkownika końcowego link: Interfejs jest dostępny w języku polskim i angielskim, możemy również zmienić motyw na ciemny/jasny.

Inne zastosowania

Aplikacja była budowana w konkretnym celu, jednak oczywiście nie oznacza to, że udostępnianie backupów to jej jedyne zastosowanie! Może być używana wszędzie tam, gdzie potrzebne jest łatwe udostępnianie plików przez web - bez kont, uprawnień i nadmiaru niepotrzebnych opcji. Ja używam jej nawet w swoim homelabie na serwerze z instalkami, z którego nie chciałem już robić kolejnego NAS-a. Mimo wszystko nie zdecydowałem się na wdrożenie uploadu pliku przez web - do takich zastosowań powstało już wystarczająco dużo aplikacji, jak choćby wspomniane Picoshare czy Gokapi, więc nie widzę sensu komplikować niepotrzebnie kod Bakdropa.

Porównanie do innych rozwiązań

Poniżej małe porównanie wybranych cech Bakdropa z innymi podobnymi rozwiązaniami. Podkreślę, że to również świetne narzędzia, ale po prostu w innych zastosowaniach.

Podsumowanie

Z pozoru prozaiczny problem - który jednak obecny był właściwie we wszystkich środowiskach, z którymi miałem styczność - spowodował nie tylko utworzenie nowej aplikacji, ale również opracowanie całego procesu podejścia do odtwarzania danych w tym konkretnym scenariuszu. Wydaje mi się, że takie podejście jest optymalne i ma wiele zalet.

Sama aplikacja będzie nadal przeze mnie rozwijana, a jeśli uznasz ją za przydatną, zachęcam do testowania i dzielenia się uwagami. Udostępniana jest w ramach licencji open-source (GPLv3), więc bez problemu można używać jej również komercyjnie.

FAQ

1. Czy to następny WeTransfer / Nextcloud / Filebrowser / Gokapi?

Nie, to maksymalnie prosta aplikacja wyłącznie do udostępniania plików z serwera bez żadnych “fancy” funkcjonalności.

2. Czemu nie można dodawać plików przez panel webowy?

Ponieważ to aplikacja wyłącznie do dzielenia się plikami istniejącymi w danym katalogu na serwerze.

3. Jaki jest sens istnienia Bakdrop?

Szybkie i proste udostępnianie plików za pomocą wygasających linków z możliwością usuwania plików bezpośrednio po pobraniu.

4. Czy Bakdrop jest darmowy?

Tak, jest to open-source’owy projekt udostępniany na licencji GLPv3.

Przydatne linki

• Repo Bakdropa na Githubie