Jak prawidłowo robić kopie bezpieczeństwa strony

Backup

Robisz regularnie kopie bezpieczeństwa swojej strony? Jeśli nie, to niezwłocznie zacznij. Jeśli tak, to świetnie – ale czy na pewno robisz je prawidłowo? Czy w razie problemów zawsze będziesz w stanie w miarę szybko odtworzyć swoją stronę?

Postanowiłem zebrać kilka porad, z których warto korzystać przy tworzeniu kopii bezpieczeństwa naszych stron.

Nie ufaj firmie hostingowej

Każda szanująca się firma hostingowa robi kopie bezpieczeństwa stron swoich klientów. Różne firmy robią to z różną częstotliwością (niektóre nawet co kilka godzin) i przechowują różną liczbę ostatnich backupów. Zanim wybierzemy usługodawcę, koniecznie powinniśmy zorientować się jak często robi on kopie bezpieczeństwa oraz gdzie i jak długo są one przechowywane. Jeśli backup jest robiony „co jakiś czas” i przechowywany na tym samym serwerze, na którym działa nasza strona, to powinniśmy czym prędzej rozejrzeć się za inną firmą hostingową.

Niezależnie jednak od tego, jak świetnie wygląda pod tym kątem oferta wybranej przez nas firmy, absolutnie nie powinniśmy opierać się tylko i wyłącznie na tej jednej kopii bezpieczeństwa. Prawdopodobnie w razie problemów usługodawca będzie w stanie w ciągu kilkunastu minut odtworzyć naszą stronę z backupu. Co jednak jeśli w wyniku awarii kopia ulegnie uszkodzeniu lub całkowitemu zniszczeniu?

Dlatego dobrze jest mieć ograniczone zaufanie do oferowanego przez firmę hostingową mechanizmu tworzenia kopii bezpieczeństwa i zadbać o to we własnym zakresie.

Wybierz odpowiednie narzędzie

Wtyczek dla WordPressa do tworzenia kopii bezpieczeństwa jest sporo. Ja najczęściej korzystam z BackWPup, ale wybór każdego innego (w miarę popularnego) rozszerzenia będzie równie dobry.

Wybierając narzędzie warto zapoznać się z opiniami na jego temat – głównie tymi negatywnymi, tak aby wiedzieć, z jakimi problemami najczęściej zmagają się jego użytkownicy. Zwykle większość problemów jest związana tak naprawdę z konfiguracją serwera – proces tworzenia kopii bezpieczeństwa pochłania sporą ilość zasobów (szczególnie w przypadku dużych serwisów) i czasem trzeba poświęcić chwilę na odpowiednią konfigurację wtyczki lub poprosić firmę hostingową o pomoc w znalezieniu przyczyn problemów. Różne wtyczki różnie sobie radzą z ograniczeniami serwerów – jeśli jedna nie działa poprawnie na naszej stronie, to warto mimo wszystko wypróbować inne.

Niektóre wtyczki (na przykład BackupBuddy czy płatna wersja BackWPup) potrafią robić tak zwane kopie przyrostowe, czyli zawierające tylko nowe i zmodyfikowane pliki. Pozwala to zaoszczędzić mnóstwo miejsca (szczególnie przy dużych stronach) i w pewnych przypadkach wydane na wtyczkę pieniądze mogą się dość szybko zwrócić.

Możemy też skorzystać z narzędzi do tworzenia kopii działających na serwerze, takich jak na przykład duplicity. Jeśli nasza strona działa na VPSie lub serwerze dedykowanym, to będzie to naturalny wybór. Jeśli jednak korzystamy z serwera współdzielonego, to najprawdopodobniej nie będziemy nawet w stanie zainstalować takiego narzędzia.

Wybierz miejsce przechowywania kopii

Oczywiście trzymanie kopii bezpieczeństwa na tym samym serwerze, na którym działa nasza strona, nie ma większego sensu, chociaż czasem może się okazac wystarczające – na przykład jeśli chcemy odtworzyć zainfekowaną stronę. Złośliwe skrypty zwykle nie dotykają archiwów (plików .zip czy .gz), tak więc przechowywana w ten sposób kopia nie będzie nie powinna być (komentarz) zainfekowana.

Trzeba jednak zawsze zwrócić uwagę na to, czy pliki zawierające backup naszej strony są odpowiednio zabezpieczone przed dostępem z zewnątrz. Większość narzędzi do tworzenia kopii oferuje tego typu zabezpieczenia. Na przykład wspomniana już wtyczka BackWPup posiada opcję, która automatycznie tworzy plik .htaccess blokujący dostęp do zawartości katalogu z backupami (który i tak ma trudną do odgadnięcia nazwę). Jednak jeśli to możliwe, warto przenieść ten katalog poza katalog public_html, tak aby znajdował się na serwerze w miejscu całkowicie niedostępnym z zewnątrz.

Praktycznie wszystkie wtyczki do tworzenia kopii bezpieczeństwa umożliwiają automatyczne wysyłanie ich gdzieś poza nasz serwer i z tej możliwości zdecydowanie powinniśmy korzystać.

Wybór miejsca, w którym będą magazynowane nasze kopie, zależy głównie od naszych osobistych preferencji. Najpopularniejszymi usługami, które można wykorzystać do tego celu, są Dropbox, Google Drive, Microsoft OneDrive czy Amazon S3. W praktyce najkorzystniejszą cenę ma usługa Amazonu (szczególnie jeśli nasze kopie są duże), ale jest też najtrudniejsza w konfiguracji.

Ja do przechowywania kopii korzystam z Dropboksa (dla mniejszych projektów) i Amazon S3. Dodatkowo co jakiś czas pobieram kopie na dysk swojego komputera – tak na wszelki wypadek.

Dropbox oferuje darmowe 2 GB miejsca na nasze pliki oraz kosztującą 99 euro rocznie wersję Pro, w ramach której otrzymujemy 1 TB miejsca (to wystarczy nawet do bardziej zaawansowanych zastosowań).

Cennik usługi Amazon S3 jest dość skomplikowany i trudno jest wyliczyć dokładną kwotę, jaką przyjdzie nam zapłacić na koniec miesiąca. Zaletą jest natomiast to, że płacimy tylko za miejsce, które wykorzystujemy. Ja w tej chwili w usłudze S3 przechowuję nieco ponad 70 GB danych (cały czas ich przybywa), a za ubiegły miesiąc otrzymałem rachunek w wysokości $1.20 (czyli około 4,60 zł). To naprawdę dobra cena.

Ustal częstotliwość wykonywania i okres przechowywania kopii

Jeśli robimy backup codziennie, ale przechowujemy tylko kilka ostatnich kopii, to robimy to źle. Co jeśli nagle zajdzie potrzeba odzyskania zdjęcia, które usunęliśmy miesiąc temu? Co gdy dopiero po tygodniu zauważymy, że nasza strona została zainfekowana, a ostatnia „czysta” kopia już dawno została usunięta?

Częstotliwość wykonywania kopii bezpieczeństwa powinniśmy ustalać indywidualnie dla każdej strony. Jeśli mamy stronę firmową, która zmienia się stosunkowo rzadko (na przykład raz na miesiąc), to nie ma sensu robić jej kopii codziennie. Z kolei gdy prowadzimy sklep z dużą liczbą zamówień, to backup bazy danych wypadałoby robić co najmniej raz na dobę, a nawet częściej.

Najwięcej miejsca na dysku serwera zajmują zwykle pliki multimedialne (zdjęcia, pliki audio i wideo) oraz dokumenty. Z kolei kopia bazy danych, która ma postać zwykłego pliku tekstowego, jest zwykle niewielka. Dlatego też w przypadku większych serwisów możemy tworzyć kilka kopii bezpieczeństwa z różną zawartością, co przyśpieszy nieco cały proces i pozwoli zaoszczędzić trochę miejsca, ale jednocześnie wciąż będzie zabezpieczać nas przed skutkami awarii.

Przykładowo, raz dziennie możemy wykonywać kopię bazy danych, plików motywu i naszych własnych wtyczek (takich, których nie możemy pobrać z zewnętrznego źródła) oraz listy zainstalowanych wtyczek (tak aby w razie problemów łatwo można było je odtworzyć). Raz w tygodniu możemy wykonywać backup plików multimedialnych (katalog /wp-content/uploads/) oraz (opcjonalnie) kompletną kopię całej strony (aby w razie awarii można było szybko odtworzyć serwis na innym serwerze). Wszystko zależy od tego, co i jak często jest dodawane lub modyfikowane na naszej stronie.

Kopie najlepiej robić w nocy, gdy serwer jest najmniej obciążony i gdy nikomu nie będziemy tym procesem przeszkadzać.

Jeśli chodzi o czas przechowywania kopii bezpieczeństwa, to również jest to kwestia indywidualna. Dodatkowym czynnikiem jest przestrzeń dyskowa, jaką możemy przeznaczyć na magazynowanie backupów. W miarę bezpieczną opcją jest przechowywanie kopii z ostatnich 30 dni. Jeśli nasza strona jest naprawdę duża, to może wymagać to sporej ilości miejsca – nie warto jednak na tym oszczędzać, bo koszty braku backupu po awarii mogą być wielokrotnie wyższe.

Ja zwykle przechowuję 30 ostatnich kopii codziennych i 12-15 ostatnich kopii tygodniowych (całościowych). Uważam, że jest to dobra metoda ze sporym marginesem bezpieczeństwa – ale na szczęście jeszcze nigdy nie musiałem z tych backupów korzystać. Jak do tej pory zwykle spotykałem się z sytuacjami, w których kopii nie było w ogóle lub były robione źle (czegoś w nich brakowało, były robione zbyt rzadko lub nie były przechowywane odpowiednio długo).

Wybierz co znajdzie się w kopii

Teoretycznie do odtworzenia serwisu zbudowanego na WordPressie wystarczy baza danych, lista zainstalowanych wtyczek oraz zawartość katalogów /wp-content/uploads/ i /wp-content/themes/ (jeśli korzystamy z własnego motywu lub z motywu potomnego). Samego WordPressa (w dowolnej wersji) i wszystkie wtyczki można zawsze pobrać z repozytorium, tak więc nie ma sensu archiwizować tych plików. Z drugiej jednak strony, znacznie szybciej jest odtworzyć serwis z kompletnej kopii – wystarczy tylko rozpakować archiwum backupu, zaimportować bazę danych i wprowadzić nowe dane bazy danych do pliku wp-config.php. Taka kompletna kopia będzie na pewno lepsza w przypadku stron, których niedostępność przynosi wymierne straty, przez co czas potrzebny na ponowne ich uruchomienie powinien być jak najkrótszy.

Koniecznie należy też przyjrzeć się niestandardowym katalogom znajdującym się wewnątrz katalogu /wp-content/. Wiele wtyczek (na przykład do tworzenia galerii) zapisuje tam swoje dane, które również powinniśmy dołączyć do naszej kopii bezpieczeństwa. Jeśli dodatkowo korzystamy z własnego motywu i niestandardowych wtyczek, może się okazać, że najbezpieczniej i najwygodniej będzie po prostu dołączyć do backupu cały katalog /wp-content/ (wykluczając tylko – jeśli jest taka potrzeba – katalog cache i katalog, do którego trafiają archiwa z kopiami bezpieczeństwa).

Dyskusyjne jest dołączanie do archiwum pliku wp-config.php. Znajdują się w nim dane, które raczej powinniśmy chronić: nazwa użytkownika i hasło bazy danych oraz klucze zabezpieczające informacje przechowywane w ciasteczkach. Jednak w większości przypadków dane te są i tak mało użyteczne – do bazy zwykle nie da się dostać z zewnątrz (spoza serwera), a wykorzystanie kluczy do jakiegokolwiek ataku jest dość trudne (a po jakichkolwiek problemach z bezpieczeństwem strony i tak powinniśmy je zmienić).

Ponieważ odtworzenie zawartości pliku wp-config.php jest bardzo łatwe (wystarczy skopiować znajdujący się w paczce instalacyjnej WordPressa plik wp-config-sample.php i uzupełnić brakujące w nim informacje), osobiście nie polecam mimo wszystko dołączania go do kopii bezpieczeństwa. Jeśli konfiguracja naszej stronie jest nieco bardziej złożona, dodatkowe ustawienia możemy trzymać w zewnętrznym pliku, który dołączamy (na przykład za pomocą funkcji require()) do pliku wp-config.php.

Podsumowanie

Na koniec jeszcze raz apeluję, abyście nie lekceważyli wykonywania kopii bezpieczeństwa – konfiguracja backupu powinna być jedną z pierwszych czynności, jakie wykonujemy po uruchomieniu nowej strony. Nikt z nas przecież nie chce, aby efekt ciężkiej (często wieloletniej) pracy zniknął bezpowrotnie.

Życzę Wam jednocześnie, abyście ze swoich wykonywanych regularnie backupów nigdy nie musieli korzystać.

Bezpośredni link

  • osabzyk

    Ze swojej strony mogę polecić wtyczkę UpdraftPlus Backup and Restoration dzięki której możemy zrobić kopie na Dysk Google

    • Czu jest ona darmowa?

      • Jest za darmo. Wersja premium płatna. Ale darmowa wersja w zupełności wystarcza. Korzystam z niej i jestem zadowolony

      • Updraft wersje free i premium.
        Korzystam z niej od 1,5roku w kilku projektach. Działa idealnie.
        Po przywróceniu ackupu strony działają bezproblemowo. Restore robiłem naście razy i nigdy nie musiałem niczego poprawiać.

    • Również korzystam z UpdraftPlus. Natomiast w tej wtyczce brakuje mi jednej funkcjonalności – dodawania własnych plików do kopii bezpieczeństwa. Mam własny php z konfiguracją WP i nie mogę go zabezpieczyć.

  • „Złośliwe skrypty nie dotykają w ogóle archiwów (plików .zip czy .gz), tak więc przechowywana w ten sposób kopia nie będzie zainfekowana.”

    Z tym stwierdzeniem bym uważał. Owszem, zazwyczaj złośliwe skrypty nie dotykają archiwów, ale… To nie jest tak, że nie mają możliwości technicznej, aby je modyfikować. A to znaczy, że nie możesz mieć żadnej pewności, że te archiwa są niezmienione – jeśli jakiś skrypt je zmodyfikuje, to nawet nie będziesz tego świadomy.

    Ogólnie sugerowałbym przyjąć założenie, że jeśli na naszym serwerze buszuje już jakiś malware, to wszystkie pliki, które mogą być modyfikowane przez serwer, są skompromitowane.

    Dotyczy to zarówno plików PHP, JS, ale także zupełnie „niewinnych” archiwów czy nawet obrazów (pliki JPG były już np. wykorzystywane do ukrywania złośliwego kodu PHP).

    • Oczywiście masz trochę racji – techniczna możliwość jest, ale zwykle nie jest ona wykorzystywana, bo w znacznej większości przypadków taka próba i tak skończyłaby się niepowodzeniem (np. przez przekroczony czas wykonywania skryptu). Inna sprawa, że większość WordPressowych malware jest zbyt prosta żeby coś takiego robić. ;)

      Co do ukrywania kodu PHP w obrazkach – to jest zupełnie inna kwestia. To tak naprawdę zmiana nazwy pliku skryptu z .php na .jpg (co ma na celu „ukrycie” kodu), a następnie „zmuszenie” interpretera do jego wykonania.

      • OK, ale to, że coś nie jest wykorzystywane, nigdy nie powinno być brane pod uwagę przy planowaniu akcji na wypadek awarii/infekcji (a przecież po to robimy backupy, co nie?) Z dużym prawdopodobieństwem po infekcji, atakujący nie wykorzysta też Twoich danych dostępowych do bazy danych czy haseł usera WP, a jednak dla czystego spokoju radziłbym je zawsze po wyczyszczeniu infekcji zmienić.

        Z plikami na serwerze jest podobnie – jeśli nie jesteś w stanie zweryfikować i zapewnić, że backup nie został zmodyfikowany, to radziłbym jednak traktować go jako skompromitowany i mu nie ufać – nie masz żadnej pewności, co jest w tym archiwum.

        Inna sprawa to to, że nie jest wykorzystywane dziś, bynajmniej nie oznacza też, że nie będzie wykorzystywane jutro – albo, że po prostu nie odkryłeś jeszcze, że jest wykorzystywane.

        Stanowczo nie zgodzę się także z twierdzeniem, że większość malware’u jest prosta. Wbrew pozorom, większość infekcji, które usuwamy klientom, to całkiem przemyślnie napisane i ukryte fragmenty kodu. (Aczkolwiek rozumiem, że to może być kwestia survivor bias i że po prostu do nas trafiają te infekcje, z którymi wcześniej ktoś sobie nie poradził – rzeczywiście często czyścimy strony, które już wcześniej „były czyszczone”).

        I ostatnie… Nie rozumiem, dlaczego próba ta miałaby się skończyć niepowodzeniem czy przekroczeniem limitu czasu. Przecież mówimy o backupach, które są tworzone przy użyciu skryptów PHP – skoro Twoja strona może sobie wygenerować tego ZIPa, to w szczególności dokładnie to samo może zrobić mój skrypt umieszczony na Twoim serwerze. Ba, nawet ma łatwiej, bo ja mogę chcieć tylko zmodyfikować jeden plik w archiwum lub dodać kilka swoich pliczków – a to są prostsze i szybsze operacje niż utworzenie całego archiwum.

        • OK, masz sporo racji – przeedytowałem trochę akapit, o którym dyskutujemy. ;) Dzięki.

          Nie zgodzę się natomiast z twierdzeniem, że kod malware jest przemyślany. Widziałem naprawdę dużo tego typu śmieci i większość była kiepska, a kilka było znośnych. Dobrze napisanych i skutecznie ukrywających swoją obecność nie widziałem (i nie mów, że były tak skuteczne, że ich nie znalazłem ;)).

          Co do modyfikacji plików ZIP czy GZ, to zapominasz jeszcze o tym, że taki malware najpierw musiałby znaleźć plik, który powinien zmodyfikować. ;)

          • Po to są dyskusje :)

            Może na takie trafiasz. Mi zdarzyło się już widywać swego rodzaju perełki, gdzie autor naprawdę wykazał się sporą wiedzą z zakresu PHP, żeby obejść typowe problemy ukrycia swojego kodu w czyimś kodzie – a jeśli uwzględnisz, że zrobił to automatycznie, to był to naprawdę kawał dobrej roboty.

            Zapominasz, że nie rozmawiamy o indywidualnych rozwiązaniach. Ja wcale niczego nie muszę szukać, bo nie interesuje mnie akurat Twoja strona. Biorę sobie na warsztat takiego BackWPUp, który ma 400.000+ aktywnych instalacji i dorzucam jego „obsługę” do mojego malware’u – czyli już mam pół miliona potencjalnych „klientów”. Skoro już odpalam mój kod na Twoim serwerze, to co to za problem sprawdzić czy masz akurat tę wtyczkę, pobrać jej ustawienia i zmodyfikować ZIPy z backupami – a tym samym zapewnić, że w ramach czyszczenia infekcji, „czyściciel” przywróci mój szkodliwy kod ;)

            Teraz wystarczy powtórzyć to dla kolejnych popularnych wtyczek…

            I tak – nie podejrzewam, żeby szybko komuś chciało się w takie rzeczy bawić, bo wydaje mi się, że inwestycja w ten kod się nie zwróci. Natomiast nie zmienia to faktu, że po infekcji nie możesz mieć zaufania do niczego, co było w zasięgu malware’u – chyba, że jesteś w stanie jednoznacznie potwierdzić autentyczność danego pliku.

          • Widziałem już samo-naprawiające się malware, widziałem wiele różnych metod na ukrywanie kodu (włącznie z kodem częściowo generowanym losowo, tak aby miał jak najmniej niezmiennych i rozpoznawalnych fragmentów), ale sama specyfika PHP (język interpretowany) powoduje, że dość trudno jest ukryć kod, który robi coś dziwnego. Poza tym z każdym kolejnym dodanym algorytmem malware się rozrasta, a powinien być możliwie mały.

            Myślę, że w ostatnim akapicie dotarłeś do sedna – nikomu nie opłaca się robić takich zaawansowanych rzeczy, bo znacznie efektywniejsze jest nap***anie na oślep po WordPressach w poszukiwaniu popularnych dziur. ;)

          • Bardziej się opłaca… Tak, na pewno tak. Ale to jest tak samo, jak z każdą wojną zbrojeń – malware będzie się stawał coraz mądrzejszy i to już w ciągu ostatnich lat można zaobserwować…

          • Odgrzeję naszą dyskusję, bo mnie zainspirowałeś. W Trójmieście miałem prezentację o malwarze i jeden z punktów dotyczył backupów. Jest nagranie, więc:
            https://www.youtube.com/watch?v=sKCRUBhiusY (okolice 32 minuty)

          • Trochę minąłeś się z prawdą. ;) Nie napisałem w żadnym miejscu, że nie ma znaczenia, czy backupy sa przechowywane u siebie czy na zewnętrznym serwerze – to zbyt daleko idące uproszczene. Napisałem dokładnie tak:

            „(…) trzymanie kopii bezpieczeństwa na tym samym serwerze, na którym działa nasza strona, nie ma większego sensu, chociaż czasem może się okazac wystarczające – na przykład jeśli chcemy odtworzyć zainfekowaną stronę. Złośliwe skrypty zwykle nie dotykają archiwów (plików .zip czy .gz), tak więc przechowywana w ten sposób kopia nie powinna być ([link do Twojego komentarza]) zainfekowana.”

            W naszej dyskusji przyznałem Ci rację, że istnieje techniczna możliwość stworzenia skryptu, który modyfikuje archiwa z backupem.

            A prezentacja jak zwykle ciekawa. :)

          • Bartosz, no więc właśnie wyraźnie pokazałem, dlaczego szczególnie w odtwarzaniu zainfekowanej strony NIE NALEŻY używać backupów leżących na serwerze (w szczególności backupy takie NIE SĄ wystarczające). Wiara, że nie są one zmodyfikowane to czysta naiwność, bo jest to kwestia dosłownie 5 linijek kodu i około 2-3 minut.

            Natomiast w stwierdzeniu „nie są zwykle modyfikowane” strasznie kłuje mnie to „zwykle”, bo nie bazuje na żadnych miarodajnych statystykach – owszem, widziałem już modyfikowane backupy na zainfekowanych stronach klientów.

          • Rozumiem, że Twoje doświadczenie jest miarodajną statystyką, ale moje już nie?…

          • Nie twierdzę, że moje sa miarodajne. Bardzo fajnie natomiast rozbiegają się z Twoimi obserwacjami, więc się nimi dzielę w roli kontrprzykladu/wyjatku.

          • To może inaczej: mógłbyś wskazać taki malware, który modyfikuje archiwa z backupami?

          • Paweł Knapek

            Prezka jak zwykle fajna, taka życiowa. Szkoda tylko jakości audio – pytania publiki praktycznie niesłyszalne …ale pewnie standardowo „Jaką zatem wtyczkę polecasz” albo „Więc jak żyć?” ;p

            Co do liczników, to stosunkowo prosto można skorygować filterkiem views_users, ale trzeba pojechać też globala $wp_list_table, bo paginacja kłamie. Wieki temu się tym bawiłem i w celach edukacyjnych popełniłem mało ładnego (ale nadal działającego) gotowca na ukrywanie „lewego”.
            Choć i tak dobrze wiemy, że nie potrzeba do szczęścia żadnego konta czy dostępu do kokpitu. ;)

        • Paweł Knapek

          Ja was pogodzę. Przyjmijmy, że do backupa należy po prostu podchodzić z dystansem ;)
          -nawet zewnętrznego.
          W tej materii statystyka i branie czegokolwiek za pewnik bywają złudne.

          • @Pawel: Z tym twierdzeniem jak najbardziej się zgodzę. Wyjątkowo backupowi możesz ufać w pełni tylko wtedy, gdy jesteś w stanie zagwarantować jego zawartość.

  • Przyznam, że bardzo przydatny wpis. Sama miałam ogromny problem po tym jak ktoś zrezygnował z serwera, na którym miałam stronę bez uprzedzenia. W efekcie kosztowało mnie trochę, żeby odzyskać całą bazę.

  • Robert

    Zarówno BackWPUp jak i UpdraftPlus robia archiwa z plikami bez polskich znaków (np. Ok+éadka zamiast Okładka). Ktoś wie jak to obejść?

    • Robert

      Na prawdę nikt nie miał z tym problemu? Czy nie macie ochoty podpowiedzieć ;)?

      • Ja nigdy nie miałem takich problemów z jednego prostego powodu – nie używam polskich znaków w nazwach plików i wszystkim polecam to samo. ;)

      • Paweł Knapek

        Pytanie tylko, czy robi faktycznie bez polskich znaków, czy tylko ich nie widzisz? – bo to, że ich nie widzisz, nie znaczy jeszcze, że ich tam nie ma ;)
        Na jakiej platformie robisz backup, na jakiej sprawdzasz (i jak) jego zawartość?
        -bo międzyplatformowe trudności to normalka i dobrą praktyką właśnie jak wspomniał Bartosz jest filtrowanie nazw/używanie bezpiecznego zestawu znaków.
        Inaczej trzeba kombinować. Teraz przykładzik: Klient ucieka z hostingu na windzie do firmy na linuxie, na stronie ma oczywiście ogoniaste pliki. Normalne przerzucenie = krzaki. Całość leci po shellu, ale najważniejsze, że po zwykłym wypakowaniu na serwerze docelowym były krzaki …ale już drobna modyfikacja komendy: unzip -UU backup.zip sprawiała, że tę samą paczkę wypakowywało z właściwym zestawem znaków ;)

        • Robert

          Dokładnie tak jak piszesz :D
          Zwykły podgląd i rozpakowanie pod windą powoduje krzaczki w nazwach ale już np. 7zip pozwala na wypakowanie z diakrytykami. Yuhu!!!
          Dzięki :)

      • To nie jest kwestia tego, że wtyczki robią coś źle.

        Polskie znaki mają różne standardy kodowania. Jeśli serwer jest linuxowy, to koduje je inaczej niż np. Twój komputer z Windowsem.

        Jeśli więc archiwum wykonane jest na serwerze, a potem pobierasz je na Windowsa i tam rozpakowujesz, to kodowania się sypią i powstają krzaki.

        Co gorsze – będziesz miał trochę zabawy z przywracaniem lub weryfikacja poprawnosci takiego backupu ;)

        • Robert

          Tak jest, zwracam honor autorom wtyczek ;) Polskie znaki są, tylko trzeba je odpowiednio rozpakować.