Podstępne podstępniki

https://xpil.eu/b00h

Blog ów siedzi sobie na platformie WordPress, hostowanej przeze mnie samodzielnie na serwerze VPS, o czym zresztą już parę razy pisałem. Ponieważ Murphy nie śpi, trzeba się zabezpieczać przed najgorszym, a więc trzy lata temu zdecydowałem się na wykupienie natywnego backupu od producenta, pod dźwięczną nazwą Vaultpress.

Przyjemność ta kosztowała mnie wówczas $45 rocznie, czyli na tamte czasy jakieś €39, czyli pi x drzwi €3 z hakiem miesięcznie. Bez tragedii. W zamian za tę skromną opłatę Vaultpress gwarantował dzienne kopie zapasowe od dnia #1 do końca świata.

Gdzieś tam po drodze zdarzyła mi się jedna czy dwie awarie (spowodowane głównie tym, że niepotrzebnie wtykałem paluchy między kółka wordpressowej machiny), z których byłem w stanie się wykaraskać właśnie dzięki tym kopiom Vaultpress. Przy okazji stwierdziłem, że ich procedura automatycznego odtwarzania kopii zapasowej nie zawsze działa tak jak powinna - ale przynajmniej za każdym razem byłem w stanie pobrać z ich repozytorium świeżą kopię bazy danych oraz systemu plików, a więcej mi nie było trzeba, więc nie ma się co czepiać drobiazgów.

Ponieważ biznes to biznes i nic nie trwa wiecznie, okazało się, że cena rocznego abonamentu odrobinę fluktuuje:

... co w przeliczeniu na nasze zaczyna się już zbliżać do €50 rocznie, a więc już €4 miesięcznie (z hakiem). Nadal nie są to jakieś kolosalne pieniądze, ale...

Raz na jakiś czas zaglądam w ichni interfejs administracyjny żeby mieć spokój ducha, że kopia faktycznie działa i Wogle. I co się okazało? Otóż jakiś czas temu Vaultpress porzucił ideę przechowywania kopii zapasowych przez wieczność i teraz ograniczają się do ostatnich 35 dni.

Wszystko fajnie, ale czemu mnie o tym nie poinformowali? A może ja chcę w napadzie nostalgicznej melancholii połączonej z melancholijną nostalgią zobaczyć jak wyglądał mój blog 3 lata temu?

No i jeszcze, skoro teraz jest "tylko" 35 dni bufora, to powinni też chyba trochę opuścić z ceny, c'nie? Tymczasem raczej się na to nie zapowiada.

Oczywiście jest też druga strona medalu. Jeżeli zajrzy się na stronę Vaultpress, to zobaczy się tam, że faktycznie najtańsza opcja kosztuje około €4.50 miesięcznie i daje tylko 10GB przestrzeni na kopie, tymczasem mój blog to okolice 7GB na chwilę obecną, co przemnożone przez 35 dni daje jakieś ćwierć terabajta, a więc całkiem sporo. No ale jednak powinni byli mnie o tym skróceniu poinformować, tak czy siak.

Rozważam więc rezygnację z Vaultpress i wdrożenie jakiegoś własnego systemu kopii zapasowej. W końcu mam domowego NAS-a z pierdzibajtami dostępnej przestrzeni dyskowej, mam też w połowie puste dwuterabajtowe konto Dropbox, trzeba to jakoś wykorzystać...

Nie dziś nie jutro - ale warto pokombinować.

Jeżeli więc, Czytelniku sympatyczny, masz swój blog na WordPress i robisz kopie zapasowe jakimś automatem, chętnie łyknę trochę pomysłów. Najlepiej żeby było prosto, tanio i pewnie (i nie, że wybierz dwa z trzech...)

🙂

https://xpil.eu/b00h

10 komentarzy

    1. Mam w sumie od jakiegoś czasu proces na swoim NAS-ie, który cztery razy na dobę ściąga z VPS-a kopię bazy WordPress, plus – rsync-em właśnie – wszystkie pliki z folderu blogu. Ale to się trochę kojarzy ze sznurkiem od snopowiązałki. Kolejna kopia bazy nadpisuje poprzednią, więc jak się coś sypnie i nie zareaguję przez max 6 godzin, to ląduję w czarnej głębokiej. Muszę przysiąść do tego, i zrobić coś bardziejszego we wolnej chwili.

      A syncthing to już od jakiegoś czasu się przymierzam, zwłaszcza na smartfona, bo klient Dropbox pod Androida to jakieś nieporozumienie jest.

    1. Obstawiam, że większość tego to moje comiesięczne podśmie-za-przeproszeniem-chujki. Parędziesiąt obrazków co miesiąc, to tego od czasu do czasu jakiś filmik albo dwa, i się nazbierało…

  1. Ale czy takie częste backupy naprawdę Ci są potrzebne? Robiąc samodzielnie kopię zapasową dwa razy w tygodniu w najgorszym razie stracisz dwie notki i z dziesięć komentarzy. Szkoda, wiadomo, ale zaoszczędzisz kilkadziesiąt euro rocznie. 🙂 Przypuszczam zresztą, że nie piszesz notek bezpośrednio w edytorze, tylko w jakimś zewnętrznym programie…? Więc brudnopis i tak ocaleje.

    ” tymczasem mój blog to okolice 7GB na chwilę obecną, co przemnożone przez 35 dni daje jakieś ćwierć terabajta, a więc całkiem sporo.”
    Pochwalę się nowo nabytą wiedzą związaną z czytaniem o i używaniem systemu plików ZFS. Ćwierć terabajta to chyba nie. Przypuszczam, że każda kolejna kopia zapasowa to po prostu patche opisujące zmiany względem poprzedniej wersji. Więc całość zajmuje bazowe 7 GB plus (liczba kopii) * (średnio kilkaset kilobajtów).

    1. >> Ale czy takie częste backupy naprawdę Ci są potrzebne?

      Absolutnie nie. Ale tak samo ludzie nie potrzebują włazić na szczyty gór, a włażą, bo mogą 🙂 Pięć dyszek rocznie to jeszcze nie jest tragedia, ale biorąc pod uwagę trend, właśnie po to próbuję to sobie zautomatyzować we własnym zakresie, żeby mnie nie ugryzły kolejne podwyżki.

      >> … Pochwalę się nowo nabytą wiedzą związaną z (…) ZFS.

      O, dobrze wiedzieć.

      >> Przypuszczam zresztą, że nie piszesz notek bezpośrednio w edytorze, tylko w jakimś zewnętrznym programie (…)

      Na ogół we wbudowanym edytorze. Czasem, jak jest jakaś dłuższa forma, przygotowuję wstępnie w Obsidianie, ale to naprawdę sporadycznie.

    2. Jeśli chodzi o backupy przyrostowe, to nie potrzeba ZFS. Duplicity czy restic potrafią robić przyrostowe backupy, niezależnie od filesystemu. Tylko wydaje mi się, że to w dzisiejszych czasach trochę overkill dla backupu bloga zajmującego kilka GB.

  2. Nawet za darmo możesz mieć VPS u Wiodących Operatorów Chmury w ramach always free tier. Takie rozwiązanie załatwia zarówno temat przestrzeni na backupy, jak i mechanizmu.

    Rozwiązania proste są dobre. Jeśli komuś kojarzą się ze sznurkiem – trudno. Czasem sznurek jest najlepszy.

    Możliwości backupu bloga/z czego korzystałem.
    Dawno temu korzystałem z backend agnostic rozwiązania opisanego tu
    https://zakr.es/blog/2012/05/jak-zrobic-backup-bloga/ Znaczy się rekursywne pobieranie przy pomocy wget. Mało eleganckie, ciężkie, ale… działa na wszystkim, nie tylko WordPress. I czasem nie ma wyboru.
    Wada jest taka, że nic opublikowanego nie zginie, ale odtwarzanie jest mało przyjemne, tj. bez dodatkowego skryptu nie podchodź. IIRC tak migrowałem się z Blox na WordPress. Z tego rozwiązania postawiony jest backup starego, joggerowego bloga.

    We wpisie dedykowanym wtyczkom do WordPressa opisałem jedną, której początkowo używałem do backupu. https://zakr.es/blog/2019/03/wtyczki-do-wordpressa/ Działało, miało wiele funkcji i… polecam zerknąć, przy Twoich wymaganiach. Umie wrzucać na chmury, drive’y, dropboxy. BackWPup.

    Tylko ja tego wszystkiego nie potrzebowałem. Od wrzucania backupu wolę zaciąganie na miejsce docelowe – tak jest bezpieczniej.

    Obecnie korzystam z prostego skryptu w cronie, który:
    1. Robi dump bazy do pliku.
    2. Tworzy skompresowane archiwum tar z ww. dumpem i całym katalogiem www. Z wykluczeniem katalogów typu cache. Czyli trochę więcej niż samym blogiem.

    Takie archiwum pobieram na inną maszynę. Mógłbym oczywiście to ulepszyć, bawić się w backupy różnicowe itp. ale… nie mam motywacji. Odtwarzam i tak całość, jest to trywialne w obsłudze. Dane nie zajmują dużo miejsca – backup wszystkich maszyn to mniej niż 10 GB.

    Jeśli chodzi o retencję, to backupy robię raz na miesiąc. W najgorszym razie stracę miesiąc danych[1], a tak rzadki backup pozwala na robienie dodatkowej kopii offline. Trzymam 2 ostatnie miesiące, plus każdy styczniowy.

    [1] Tak naprawdę jeśli chodzi o bloga to pewnie nic nie stracę, bo treść wpisów i komentarze mam też w czytniku RSS.

    1. >Nawet za darmo możesz mieć VPS u Wiodących
      >Operatorów Chmury w ramach always free tier.

      Chyba już nie. Szukałem ostatnio czegoś prostego, ale darmowego, żeby pobawić się VPS-em, ale najwyraźniej wiele always free tierów pozamykało się w przeciągu ostatnich paru lat. Te, które pozornie są always free, albo nie są always, albo nie są free.

Leave a Comment

Komentarze mile widziane.

Jeżeli chcesz do komentarza wstawić kod, użyj składni:
[code]
tutaj wstaw swój kod
[/code]

Jeżeli zrobisz literówkę lub zmienisz zdanie, możesz edytować komentarz po jego zatwierdzeniu.