Migracja filmów kursu: WordPress widział 14 plików, API dostawcy 31

14 filmów w WordPressie, 31 plików u dostawcy

Przenosiliśmy filmy kursów klientki od jednego dostawcy do drugiego. Klasyczna migracja plików z S3 przed skasowaniem konta, które miało przestać kosztować. Plan był prosty: przenieść, sprawdzić, skasować stare konto, żeby przestało generować koszt. Z bazy WordPressa wyszło 14 filmów podpiętych w kursach. Lista wyglądała na kompletną i w takiej formie poszła dalej.

Potem zrobiliśmy listing bezpośrednio przez API dostawcy. Pokazał 31 plików. Wśród nich całe nagranie sesji Q&A, którego nie było w żadnym kursie, i logo używane na stronie głównej. Gdyby konto zniknęło według listy z WordPressa, klientka straciłaby nagranie, a jej strona – logo. Ten tekst jest o tym, jak przenosić pliki z chmury i zamykać stare konto tak, żeby nic nie przepadło po cichu.

Kontekst: dlaczego w ogóle ruszaliśmy filmy

Klientka prowadzi platformę kursową na WordPressie. Filmy kursów leżały w magazynie obiektowym zgodnym z S3 (Wasabi), a lekcje w kursach korzystały z plików zapisanych w buckecie. Docelowo filmy miały trafić do Bunny Stream – usługi stworzonej do wideo, z własnym odtwarzaczem i kodowaniem pod różne łącza.

Był też drugi zapalnik, który przypomniał nam, jak ciche bywają usługi w chmurze. Na innym koncie, używanym do kopii zapasowych, darmowy próg 10 GB był już przekroczony – zajętych było około 11,1 GiB. Powyżej darmowego progu, bez podpiętej karty, zapis się blokuje. Kopie zapasowe przestają się robić i nikt nie dostaje o tym alarmu. Porządki w kontach dostawców miały więc sens nie tylko kosztowy.

Pierwsza odpowiedź, która wyglądała na pełną

Naturalny pierwszy krok: wyciągnąć z bazy WordPressa wszystkie lekcje, które mają film, i zebrać adresy. Wyszło 14 pozycji. Każda z adresem do bucketu, każda przypisana do kursu. Wszystko się zgadzało, nic nie wyglądało podejrzanie.

I właśnie to jest pułapka. Lista z aplikacji jest wiarygodna dokładnie w tym zakresie, który aplikacja zna. WordPress wie o filmach, które ktoś podpiął w lekcji. Nie wie o pliku, który klientka wgrała do bucketu sama, o logo wstawionym w Elementorze pełnym adresem ani o plikach technicznych, które zostawił wcześniejszy wykonawca.

Moment odkrycia: listing z API dostawcy

Zanim ktokolwiek dotknął przycisku „usuń konto”, zrobiliśmy inwentaryzację z drugiej strony – bezpośrednio z API magazynu, z jawną paginacją, po wszystkich folderach. Wynik:

• 15 filmów, a nie 14 – w tym nagranie sesji Q&A o wadze około 1,4 GB, nie podpięte w żadnym kursie,
• 2 pliki logo, które istniały wyłącznie u tego dostawcy – jedno z nich było logo strony wstawionym w Elementorze,
• 3 pliki techniczne,
• oraz pozostałe pliki, których nie było w żadnym widoku WordPressa.

Baza aplikacji nie może wykryć tego, czego aplikacja nie zna. Inwentaryzację przed skasowaniem konta robi się z API dostawcy, nie z panelu programu, który z niego korzysta.

To ta sama rodzina błędu, co listingi z API, które domyślnie filtrują wynik – na przykład pokazują tylko bieżący okres rozliczeniowy. Liczba wygląda wiarygodnie, nic nie krzyczy błędem, a połowy danych w niej nie ma.

Rozwiązanie: inwentaryzacja z API, a nie z aplikacji

Listing bucketu zgodnego z S3 zrobisz oficjalnym klientem AWS CLI, podając adres punktu końcowego swojego dostawcy. Nazwę bucketu i region podmień na swoje:

# Pełna lista plików z rozmiarami, rekurencyjnie, po wszystkich "folderach"
aws s3 ls s3://NAZWA-BUCKETU --recursive --human-readable --summarize \
  --endpoint-url https://s3.TWOJ-REGION.wasabisys.com

Na końcu wyniku dostajesz łączną liczbę obiektów i ich rozmiar – tę liczbę porównujesz z tym, co wyciągnąłeś z aplikacji. Jeśli wolisz Pythona, pamiętaj o paginacji. Jedno wywołanie zwraca maksymalnie 1000 obiektów, więc bez paginatora większy bucket będzie wyglądał na mniejszy, niż jest:

import boto3
s3 = boto3.client("s3", endpoint_url="https://s3.TWOJ-REGION.wasabisys.com")
pliki = []
for strona in s3.get_paginator("list_objects_v2").paginate(Bucket="NAZWA-BUCKETU"):
    pliki += [(o["Key"], o["Size"]) for o in strona.get("Contents", [])]
print(len(pliki), "plików,", round(sum(r for _, r in pliki) / 1024**3, 2), "GiB")

Tak samo postępujesz z każdą inną usługą w chmurze: CDN, magazynem kopii, hostingiem plików. Lista z API dostawcy to stan faktyczny. Lista z aplikacji to tylko podzbiór.

Przenosisz kurs od jednego dostawcy do drugiego albo z gotowej platformy na własny WordPress? Opisaliśmy cały proces w poradniku o migracji platformy kursowej. A jeśli wolisz, żeby ktoś zrobił to za Ciebie i niczego nie zgubił, napisz do nas, co i skąd przenosisz.

Procedura w 6 krokach, którą stosujemy od tej migracji

1. Inwentaryzacja z API dostawcy, nie z bazy aplikacji – z jawną paginacją i podsumowaniem liczby oraz rozmiaru plików.
2. Każdy plik przypisany do jednej z grup: używany w aplikacji / nieużywany / do ściągnięcia na docelowy serwer.
3. Każdy plik nieużywany to pytanie do klienta, zanim zniknie. W naszym przypadku „nieużywany” plik okazał się nagraniem sesji, na którym klientce zależało.
4. Zasoby istniejące tylko u dostawcy (logo, grafiki, dokumenty) ściągasz na docelowe miejsce, podmieniasz adresy na stronie i sprawdzasz, czy nowy adres odpowiada kodem HTTP 200.
5. Dopiero potem zgoda na kasowanie konta – i kasuje właściciel konta, nie wykonawca. Wykonawca oddaje listę i kolejność kroków.
6. To samo przy DNS. Nowy hosting nie przenosi całej strefy domeny sam z siebie. Porównujesz rekord po rekordzie.

Efekt: nic nie przepadło

Wszystkie filmy kursów działają u nowego dostawcy. Nagranie sesji Q&A nie zniknęło razem z kontem – o tym, co z nim dalej, zdecydowała klientka. Oba pliki logo trafiły na serwer strony, zanim stary adres przestał działać. Stare konto zostało zamknięte świadomie, po zatwierdzeniu listy, a nie „na wyczucie”.

Różnica między wersją z WordPressa a wersją z API to 17 plików. W tej historii najcenniejszy był jeden z nich – nagranie, którego nie dałoby się odtworzyć.

Jak sprawdzić u siebie przed zamknięciem konta w chmurze

• Zrób listing przez API albo oficjalny klient dostawcy i zapisz liczbę oraz łączny rozmiar plików.
• Porównaj tę liczbę z tym, co widzisz w aplikacji. Każda różnica to plik do wyjaśnienia.
• Poszukaj w treściach strony pełnych adresów do bucketu – logo i grafiki wstawione w kreatorze stron nie pojawią się w bibliotece mediów.
• Sprawdź, czy konto nie przekroczyło darmowego progu i czy kopie zapasowe dalej się zapisują.
• Przy zmianie hostingu porównaj strefę DNS rekord po rekordzie, ze szczególną uwagą na SPF, DKIM i DMARC.
• Kasowanie konta zostaw właścicielowi i zrób je na końcu, po potwierdzeniu, że nowe adresy działają.

Czego nauczyła nas ta historia

Lista z aplikacji jest tak dobra, jak wiedza tej aplikacji o świecie. Przed każdą operacją, której nie da się cofnąć – skasowaniem konta, bucketu, strefy DNS – robimy inwentaryzację od strony dostawcy i konfrontujemy ją z tym, co widać w panelu. Rozjazd „u mnie 14, u dostawcy 31” nie jest szczegółem, tylko sygnałem, żeby się zatrzymać.

FAQ

Jak sprawdzić wszystkie pliki w buckecie S3?

Najprościej przez AWS CLI poleceniem aws s3 ls z opcjami --recursive i --summarize, z adresem punktu końcowego Twojego dostawcy. Wynik kończy się łączną liczbą obiektów i rozmiarem.

Dlaczego WordPress nie pokazuje wszystkich plików z zewnętrznego magazynu?

Bo zna tylko pliki, które ktoś w nim podpiął – w lekcji, w bibliotece mediów, w treści. Pliki wgrane bezpośrednio do bucketu albo wstawione pełnym adresem w kreatorze stron są dla niego niewidoczne.

Czy skasowanie konta u dostawcy da się cofnąć?

Zwykle nie, a jeśli tak, to tylko przez krótki czas i nie zawsze z danymi. Dlatego kasowanie jest ostatnim krokiem, po inwentaryzacji i sprawdzeniu nowych adresów.

Co zrobić z plikami, które nie są nigdzie podpięte?

Zapytać właściciela, zanim znikną. „Nieużywany” z punktu widzenia aplikacji nie znaczy „niepotrzebny” – w naszej historii był to cenny materiał nagraniowy.

Czy przy migracji filmów trzeba ruszać DNS?

Nie zawsze, ale jeśli przy okazji zmieniasz hosting lub dostawcę domeny, przenieś strefę rekord po rekordzie. Brak jednego rekordu DKIM potrafi zablokować maile do kursantów bez żadnego widocznego błędu.