Pag-restore sa Wayback Machine: 4 Pitfalls at Paano Maiiwasan ang mga Ito

Ginagawang madali ng Wayback Machine ang pag-restore: pumili ng petsa, makuha muli ang iyong site. Pagkatapos ay binuksan mo ang na-restore na folder at nakita ang isang pahina ng domain-parking kung saan dapat naroon ang iyong homepage, kalahati ng mga larawan ay nagbabalik ng 404, at isang footer mula 2011 na nasa ilalim ng isang pahina mula 2017. Nakapaglinis na ako ng sapat na mga bigong restore upang malaman na ang mga pagkabigo ay nahuhulaan. Ang parehong apat na pitfall ay sumisira sa halos bawat masamang pag-restore sa Wayback Machine, at bawat isa ay tumatagal ng halos sampung minuto ng pagsusuri upang maiwasan. Narito kung ano ang nagkakamali, bakit, at kung paano ito mahuhuli bago ka magbayad para sa anuman.

Bakit nagkakamali ang pag-restore sa Wayback Machine

Ang archive ay hindi backup ng iyong site. Ito ay tambak ng mga oportunistikong pag-crawl: iba't ibang pahina ang nakunan sa iba't ibang araw, ilang asset ang tuluyang nilaktawan, ilang capture ang na-trigger habang sira ang iyong site. Ang isang restore tool ay maaari lamang gumana sa kung ano ang nakuha ng crawler. Karamihan sa mga sakuna sa restore ay nagmumula sa pagtrato sa archive bilang perpektong salamin at paglaktaw sa mga pagsusuri sa ibaba.

Pinapatunayan ito ng mga numero. Sa isang trabaho ng kliyente, isang 2009 phpBB forum na may humigit-kumulang 8,000 naka-archive na URL, ang pinakabagong anim na buwan ng mga snapshot ay pawang mga redirect capture na nakaturo sa isang domain reseller. Ang pag-restore mula sa default na pinakabagong petsa ay maghahatid sana ng 8,000 kopya ng isang for-sale page. Naroon ang magandang data, dalawang taon na mas maaga. Maayos ang tool; ang pagpili ng petsa ang buong laro.

Pitfall 1: Pag-restore ng isang parked page

Nag-e-expire ang mga domain, pina-park ito ng mga registrar, at masayang kinukuha ng Wayback Machine ang parking page. Sa view ng kalendaryo, ang mga capture na iyon ay mukhang kapareho ng mga mabubuti, parehong asul na bilog, parehong timestamp. Ang palatandaan ay lumalabas lamang kapag binuksan mo ang snapshot: mga ad kung saan dapat naroon ang iyong nilalaman, isang banner na nag-aalok ng domain for sale, isang logo ng registrar sa sulok.

Madalas na unang tumatama ang parking sa homepage habang ang mga mas malalim na pahina ay nagpapakita pa rin ng tunay na nilalaman, kaya hindi sapat ang mabilisang tingin sa isang pahina. Nakakita na ako ng mga restore kung saan ang homepage ay isang parked page mula 2020 at ang about page ay tunay na nilalaman ng 2016, ang na-restore na site ay parang ransom note.

• Buksan ang aktwal na snapshot, hindi lamang ang thumbnail ng kalendaryo, bago pumili ng petsa
• Suriin ang homepage at hindi bababa sa dalawang panloob na pahina mula sa parehong panahon
• Kung ang mga kamakailang snapshot ay naka-park, balikan ang kalendaryo hanggang sa huling capture na may tunay mong disenyo
• Kumpirmahin na ipinapakita ng snapshot ang iyong nabigasyon, hindi ang link farm ng isang registrar

Pitfall 2: Mga redirect chain at capture loop

Kapag nagsimulang mag-redirect ang isang site, lumang domain patungo sa bagong domain, http patungo sa https, non-www patungo sa www, nire-record ng crawler ang redirect, hindi ang nilalaman. Mag-restore mula sa mga capture na iyon at makakakuha ka ng mga pahinang nakaturo sa mga pahinang nakaturo sa mga pahina. Ang klasikong kaso: ang huling taon ng mga snapshot para sa isang site na lumipat ng domain ay walang iba kundi mga 301 capture, at tumigil ang pag-archive ng nilalaman sa araw na nangyari ang paglipat.

Ang masamang variant ay ang redirect loop: ang pahina A ay nagre-redirect sa pahina B, ang pahina B ay nagre-redirect pabalik sa A, at ina-archive ng crawler ang parehong pagtalon. Sumusuko ang mga browser pagkatapos ng ilang pagtalon at ganoon din ang iyong mga bisita.

May dalawang bahagi ang solusyon. Mag-restore mula bago nagsimula ang mga redirect, at panatilihin ang mga sadyang redirect rule na live sa panahon ng iyong napiling window sa halip na ang mga sirang chain na naitala ng crawler. Sa Restorix, ginagawa iyan ng opsyong keep-301/302, pinapanatili nito ang mga intensyonal na redirect at inaalis ang mga aksidental. Kung mano-mano kang magre-restore, i-grep ang na-download na HTML para sa mga archive.org redirect wrapper bago mag-upload ng anuman; nagtatago ang mga ito sa mga meta refresh tag at canonical link.

Pitfall 3: Mga nawawalang larawan at sirang asset

Magalang ang mga crawler. Nirerespeto nila ang robots.txt, sumusuko sa mabagal na server, at nilalaktawan ang mga file na lampas sa limitasyon ng laki. Ang mga larawan ang unang nasasakripisyo. Maaaring makuha ang isang pahina nang dalawampung beses habang ang hero image nito ay hindi kailanman nakuha. Mawawala rin ang mga asset na nasa likod ng hotlink protection o nasa isang CDN subdomain na hindi pinansin ng crawler.

Ang pinakamalalang salarin ay ang mga background image na nire-reference mula sa mga CSS file. Maayos na naa-archive ang HTML ng pahina, maayos na naa-archive ang stylesheet, at ang 400 KB na larawang tinutukoy ng stylesheet ay hindi, kaya ang pahina ay nare-restore na may kulay abong kawalan kung saan dating naroon ang disenyo. Mapapansin mo lamang ito kapag binuksan mo ang na-restore na site, maliban kung susuriin mo muna.

• Suriin ang file manifest para sa bawat-file na capture status sa halip na ipagpalagay na mayroong larawan
• Asahan ang mga puwang sa /uploads/ folder sa mga site na maraming larawan at maglaan ng oras upang maghanap ng mga kapalit
• Tanggapin na anumang nasa likod ng login, form POST, o JavaScript rendering ay wala talaga sa archive
• I-spot-check ang limang random na larawan sa naka-archive na snapshot bago mag-commit sa isang petsa

Walang restore tool ang makakabawi ng isang file na hindi kailanman nakuha ng archive. Ang ginagawa ng isang mahusay na tool ay ipakita sa iyo ang mga puwang nang maaga, gumagawa ang Restorix ng isang JSON/SQLite manifest na naglilista ng bawat file at ang status nito, kaya makikita mo ang mga butas sa estimate, hindi pagkatapos ng deploy.

Pitfall 4: Magkahalong timestamp sa mga pahina

Madalas na binibisita ng crawler ang iyong homepage at bihira ang iyong malalalim na pahina. I-restore ang buong site at ang homepage ay maaaring mula Marso 2019 habang ang pricing page ay mula Oktubre 2015. Ang resulta ay parang site na pinapanatili ng isang time traveler: lumang presyo, umalis na staff, isang copyright footer na hindi sumasang-ayon sa sarili nito sa bawat pahina.

Minsan ay nag-restore ang isang kliyente ng isang restaurant site at buong pagmamalaking inilunsad ito, may 2014 menu, 2017 reservations page, at 2019 homepage na nag-aanunsyo ng isang chef na umalis tatlong taon na ang nakalipas. Lahat ng file ay tunay. Ang halo ang problema.

Gumamit ng date-range selection upang ikulong ang restore sa isang magkakaugnay na window. Para sa isang brochure site, anim hanggang labindalawang buwan ay karaniwang sapat. Para sa isang forum o shop, tanggapin ang pagkalat sa mga lumang thread at pahina ng produkto ngunit i-pin ang mga pangunahing landing page sa parehong panahon. Pagkatapos ay magpatakbo ng search-and-replace sa mga halatang palatandaan: mga taon, presyo, numero ng telepono, pangalan ng staff.

Kapag ang pag-restore sa Wayback Machine ay maling tool

Minsan ay sadyang wala ang iyong site sa archive. Kung hinarang ng robots.txt ang mga crawler, kung ang buong site ay nasa likod ng login, o kung ito ay binuo pagkatapos ng huling pag-crawl at maagang namatay, walang dapat i-restore. Suriin ang kalendaryo bago magplano ng anupaman. Kapag walang laman ang archive, ang iyong makatotohanang mga opsyon ay isang web cache na kopya ng ilang pangunahing pahina, mga lumang backup mula sa dating host o developer, o muling pagbuo mula sa simula gamit ang anumang nilalaman na maaari mong masagip.

Ang pag-restore ay maling tool din kapag isang pahina lamang ang kailangan mo. Ang pag-save ng isang pahina mula sa archive nang mano-mano ay tumatagal ng dalawang minuto; ang buong restore ay para maibalik ang isang buong gumaganang site.

Paano suriin ang isang snapshot bago ang pag-restore sa Wayback Machine

1. Buksan ang snapshot at i-click ang tatlong antas ng nabigasyon
2. Tingnan ang source at hanapin ang mga web.archive.org wrapper na kakailanganing alisin
3. Kumpirmahin na limang random na larawan ang naglo-load mula sa naka-archive na kopya
4. Ihambing ang petsa ng pagkakuha ng homepage laban sa petsa ng pagkakuha ng isang malalim na pahina
5. Beripikahin na ang snapshot ay iyong site, hindi isang parked page, hindi isang hack defacement, hindi isang redirect
6. Itala ang buong timestamped URL upang ang restore tool ay gumamit ng eksaktong capture na iyong sinuri

Ang limang minutong pagsusuri ay mas mainam kaysa mag-restore ng 9,000 maling file. O laktawan ang manu-manong trabaho: patakbuhin ang libreng estimate sa Restorix at ipapakita nito ang eksaktong bilang ng naka-archive na file, kabuuang laki, at isang naka-lock na presyo para sa iyong napiling petsa bago ka magbayad. Kung mukhang mali ang bilang, 12 file para sa isang site na natatandaan mong may daan-daang pahina, iyan ang archive na nagsasabi sa iyo na ang snapshot ay mas manipis kaysa sa hitsura nito.

Checklist sa pag-restore sa Wayback Machine

I-print ito o panatilihing bukas sa isang tab. Bawat item ay tumatagal nang wala pang dalawang minuto, at bawat nilaktawang item ay isang restore na maaaring kailanganin mong bayaran nang dalawang beses. Kung gusto mo ang paggawa sa halip na pagsusuri, ang quick-start guide ay sumasaklaw sa mismong pag-restore nang hakbang-hakbang.

Bawat masamang restore na naayos ko ay nabigo sa pagpili ng snapshot, hindi sa pag-download. Sinasabi sa iyo ng archive kung ano ang mayroon ito, basahin ito bago mo ito bilhin.