Mabagal ang cloud backup sa VPN: hanapin ang tunay na yugto

Ang backup na gumagapang sa VPN ay nag-aanyaya sa halatang eksperimento na idiskonekta ang tunnel at muling sukatin. Madalas na ibang tanong ang sinasagot ng eksperimentong iyon, dahil maaaring nagha-hash ng mga file ang trabaho o naghihintay ng muling pagsubok sa halip na naglilipat ng mga byte. Paghiwalayin muna ang mga yugto at ang reklamo ay nagiging tiyak na pagsubok na may tiyak na inaasahang resulta. Ang ruta ay nagiging kandidato lamang kapag ang yugto ng paglilipat ang talagang mabagal.

Sa anong yugto ang trabaho kapag mabagal ang pakiramdam

Dumadaan ang mga backup tool sa mga yugto: paghahanap ng mga file, pagbasa at pagha-hash sa mga ito, pag-compress, pag-encrypt, pag-upload at pagkatapos ay pag-verify. Bawat yugto ay may sariling bottleneck, at iilan lamang sa kanila ang humahawak sa network. Ang tool na wala pang iniuulat na yugto ay nagsasabi sa iyo na hindi pa nito natapos ang pag-scan.

Ang trabahong gumugugol ng dalawampung minuto sa paghahanda ng isang milyong maliliit na file ay hindi bibilis kapag bumilis ang tunnel. Ang trabahong pumupuno sa uplink ay problema sa kapasidad na may ibang solusyon. Basahin ang output ng progreso habang nangyayari ang pagkaantala, itala ang yugto at isulat ang oras, dahil ang yugto sa sandali ng reklamo ang tanging mahalaga. Ang maliliit na file ay kumikilos din nang iba kaysa sa isang malaking bagay, dahil nangingibabaw ang mga paglalakbay pabalik-balik bawat file at hindi kailanman umabot ang paglilipat sa matatag na bilis. Ikumpara ang katulad sa katulad bago gumawa ng mga konklusyon tungkol sa tunnel.

Ang pampublikong endpoint at pribadong NAS ay nabibigo nang iba

Ang pampublikong serbisyo ng backup ay may sariling awtentikadong koneksyon ng aplikasyon, at ang tunnel ay isang hakbang lamang sa mas mahabang landas. Ang pribadong NAS ay karaniwang umaasa sa tunnel na iyon para sa pangunahing maabot ng iyong network. Ang pagkakaibang iyon ang nagtatakda kung ang pagdiskonekta ay valid na baseline o pagsubok ng wala.

Sa pampublikong kaso, ang parehong trabaho sa ibang ruta ay maaaring maging patas na paghahambing kapag pinapayagan ng patakaran. Sa pribadong kaso, ang pagtanggal ng tunnel ay walang iniiwang ruta patungo sa server, kaya inilalarawan ng resulta ang rutang tinanggal mo at hindi ang ginagamit mo.

Ang pagtigil ay ibang pagkabigo kaysa mabagal na paglilipat

Ang ikatlong kolum ng talahanayang iyon ang nagtatakda kung ang pagsubok ng katatagan ay maaaring isagawa, dahil ang baseline na nagtatanggal ng tunnel ay may kahulugan lamang kung saan may ibang landas. Sa magagamit na baseline, tingnan ang hugis ng pagkabigo at hindi ang average na bilis. Ang mababa ngunit tuloy-tuloy na pag-upload ay tumutukoy sa kapasidad, habang ang trabahong tumitigil at nagsisimulang muli ay tumutukoy sa pagkaantala, awtentikasyon o isang problematikong file. Ang dalawang ito ay gumagawa ng halos magkatulad na reklamo at ganap na magkaibang pagkukumpuni.

Binabaluktot ng mga muling pagsubok ang bawat pagsukat, dahil ang mga byte sa wire ay maaaring mas marami kaysa sa dami na talagang nagbago. Basahin ang pag-uugali ng pagpapatuloy bago muling abalahin ang trabaho upang makita ang nangyayari, dahil ang mga hinatiing naipagpapatuloy na pag-upload ay mabilis na bumangon at ang mga muling pagsisimula ng buong file ay hindi. Ang tunnel na muling kumokonekta tuwing ilang minuto ay mukhang problema rin sa bandwidth kapag talagang problema ito sa katatagan. Pinapalala ito ng MTU ng landas, dahil ang tunnel na nagpapababa ng magagamit na payload ay humihinto sa malalaking segment habang ang maliliit ay dumadaan.

journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com

Ang isang pag-upload ay maaaring magutom ang lahat ng iba pang daloy

Ang pag-upload na pumupuno sa uplink ay ginagawang hindi tumutugon ang mga tawag at pag-browse, at ang backup ay bihirang ang tanging bagay na nakikipag-agawan dito. Ang ikalawang sync client ay gumagawa ng parehong sintomas nang mag-isa. Bago sisihin ang tunnel, tingnan kung ano pa ang nag-a-upload.

Gamitin ang iskedyul o limitasyon sa bandwidth na dokumentado ng tool sa halip na makipaglaban para sa pinakamataas na throughput; ang pag-iiwan ng puwang para sa interactive na trabaho ay karaniwang mas mahalaga kaysa sa huling porsyento. Pagkatapos ay suriin kung ano talaga ang saklaw ng limitasyon, dahil ang ilang tool ay naglilimita bawat file, ang iba sa buong pagtakbo, at ang iba ay ganap na binabalewala ang gastos ng maliliit na file. Ang limitasyong hindi tugma sa workload ay walang binabago. Ang split tunneling ay dapat ding pagdudahan dito, dahil ang pagbubukod sa launcher mula sa tunnel ay hindi nagbubukod sa helper service na nagsasagawa ng pag-upload. Halimbawa, inilalathala ng Rclone ang mga limitasyon sa paglilipat at ang pag-uugali ng muling pagsubok sa dokumentasyon nito, na ginagawa itong kapaki-pakinabang na sanggunian sa kung ano ang dapat kontrolin ng isang limitasyon.

Tapusin sa pag-restore, hindi sa pagsubok ng bilis

Ang natapos na pag-upload ay hindi backup hanggang may maibalik mula rito. Kumpirmahin na umiiral ang inaasahang bersyon, pagkatapos ay i-restore ang isang representatibong file gamit ang pamamaraang dokumentado ng tool. Itago ang impormasyon ng pagbawi sa ibang lugar kaysa sa makina o profile na maaaring mawala sa iyo, at huwag kailanman itapon ang gumaganang backup para lamang mapanatiling maayos ang isang eksperimento.

restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hosts

Ulitin ang paglilipat at ang pag-restore pagkatapos ng pagbabago sa network, upang maipakita na ang pagbuti ay naglilingkod sa backup at hindi lamang naglilipat ng datos nang mas mabilis. Ang ikalawang pagtakbo ang nagsasara ng ticket. Ang mas mabilis na paglilipat na may hindi pa nasubukang pag-restore ay isang mas mabagal na paraan upang manatiling walang proteksyon.