# Checklist ng migration ng VPS: backups, DNS, TLS at rollback [Checklist ng migration ng VPS: backups, DNS, TLS at rollback]() Na-update 2026-10-15 Isang praktikal na pagkakasunod-sunod ng migration para sa self-hosted na aplikasyon: imbentaryo, tuloy-tuloy na backups, nasubok na destinasyon, kontroladong pagsusulat, DNS cutover at landas ng restore. Ang kontroladong migration ng VPS ay nag-iimbentaryo ng mga serbisyo at data, gumagawa ng tuloy-tuloy na backup, nagbeberipika ng na-restore na destinasyon, sumusubok ng hostname at TLS routing, nag-coordinate ng huling writes at DNS, at nagpapanatili ng rollback na may kamalayan sa data. Walang checklist na nag-iisa ang naggagarantiya ng zero downtime. ## I-imbentaryo ang aplikasyon bago ito ilipat Ilista ang mga serbisyo, bersyon, port, nakatakdang gawain, database, na-upload na file at configuration na kailangan upang gumana ang aplikasyon. Tukuyin kung saan nangyayari ang pagsusulat at kung aling mga panlabas na serbisyo ang pinagkakatiwalaan nito. Ang kinopyang direktoryo ng web ay hindi kumpletong migration kapag ang data ay nasa ibang lokasyon. Itala ang kasalukuyang mga pangalan ng DNS, aktibong IPv4 at mga rekord ng IPv6, mga paraan ng pag-renew ng certificate at landas ng access sa recovery. Itago ang mga secret sa iyong pribadong tooling sa deployment. Huwag ilagay ang mga password, private key o database dump sa isang pampublikong document root o sa isang nakabahaging checklist ng migration. ## Gumawa ng tuloy-tuloy na backup at patunayan na nagre-restore ito Gamitin ang mekanismo ng backup na sinusuportahan ng database sa halip na kopyahin ang mga arbitrary na file habang nagpapatuloy ang pagsusulat. Para sa SQLite, ang Online Backup na API ay lumilikha ng tuloy-tuloy na snapshot ng database. Sa mode na WAL, ang file na WAL ay kasama sa persistent na estado ng database, kaya ang pagkopya lamang ng pangunahing file ng database ay maaaring mag-alis ng mga na-commit na pagbabago. Ang tuloy-tuloy na backup ng database ay hindi awtomatikong umaayon sa hiwalay na itinatagong uploads, queues o file. I-coordinate ang kanilang pagkakakuha sa iyong aplikasyon. I-restore sa isang hiwalay na lokasyon ng pagsubok at beripikahin ang mga rekord, reference ng file at pag-uugali ng aplikasyon bago ituring na magagamit ang backup. ## Ihanda ang destinasyon bago baguhin ang DNS Gumawa ng nilalayong mga user, pahintulot, bersyon ng runtime, serbisyo at direktoryo ng aplikasyon sa bagong server. I-restore ang test backup sa destinasyon nitong lokasyon ng data, sa labas ng pampublikong web root kung naaangkop. Suriin ang pagmamay-ari at access gamit ang service account na aktwal na magpapatakbo ng aplikasyon. Panatilihin ang mga walang kaugnayang site sa isang shared server. Gumamit ng dedikadong document root, virtual host at runtime, i-validate ang configuration ng web-server at maghanda ng rollback na nagre-restore lamang ng mga file at configuration na pagmamay-ari ng pagbabagong ito. ## Subukan ang tunay na hostname at certificate sa bagong server Ang request ng browser sa isang hubad na IP address ay hindi nagre-reproduce ng routing na batay sa hostname o validation ng certificate. Ang curl --resolve ay nagpapahintulot sa isang pagsubok na gumamit ng nilalayong hostname at piniling destinasyong IP habang pinapanatili ang normal na hostname at TLS checks. Suriin din ang HTTP status at inaasahang nilalaman ng aplikasyon. Ang halimbawa ay gumagamit ng documentation-only values; palitan ang mga ito ng sarili mong beripikadong domain at destinasyon. Ang isang valid na certificate at pinapayagang landas ng network ay dapat na umiiral na para pumasa ang pagsubok na iyon. Huwag kailanman i-disable ang pag-verify ng certificate upang sabihing handa na ang migration. Ang DNS-based na ACME validation ay maaaring mag-validate ng domain nang hindi binabago ang address ng web-server nito; ang validation na batay sa HTTP ay may ibang mga kinakailangan sa reachability. Subukan ang renewal nang hiwalay sa paunang issuance. ``` curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/ ``` ## Pumili ng plano sa pagkontrol ng pagsusulat at huling sync Mag-iskedyul ng maikling panahon ng maintenance o ibang mekanismo ng consistency na naaangkop sa aplikasyon. Itigil o i-redirect ang mga writer na natukoy mo, kunin ang huling tuloy-tuloy na backup ng database, i-synchronize ang kaukulang mutable files at beripikahin ang resulta. Ang mga queue worker, webhook at cron task ay maaaring magsulat kahit na ang pampublikong interface ay tila tahimik. Gumamit ng dry run bago ang pag-synchronize ng file. Huwag magdagdag ng mga deletion flag o kopyahin ang buong direktoryo ng system bilang shortcut. Panatilihing mare-recover ang lumang serbisyo hanggang sa masuri mo ang bagong aplikasyon at matukoy kung aling lokasyon ang awtoritatibo para sa pagsusulat. ## Baguhin ang DNS, pagkatapos obserbahan ang parehong address family I-update ang mga rekord na kailangan para sa serbisyo at isaalang-alang ang umiiral na mga cache ng resolver. Suriin ang mga awtoritatibong sagot at ilang normal na landas ng client. Kung ang isang lipas na rekord ng AAAA ay nananatiling aktibo, ang mga client na IPv6 ay maaaring magpatuloy na maabot ang lumang server habang ang mga client na IPv4 ay umaabot sa bago. Subukan ang pag-sign in, pagbasa, pagsusulat, pag-upload, background jobs at panlabas na callback sa bagong serbisyo. Iwasan ang pagpapatakbo ng dalawang independiyenteng nakakasulat na kopya ng parehong aplikasyon sa panahon ng transition. Panatilihin ang malinaw na tuntunin sa paghawak ng trapikong umaabot pa rin sa lumang destinasyon. ## Gawing desisyon sa data ang rollback gayundin ang desisyon sa DNS Tukuyin ang mga kondisyon ng pagkabigo na nagpapasimula ng rollback at kung sino ang kumokontrol sa cutover. Ang pag-revert ng DNS lamang ay hindi sapat pagkatapos na umabot ang mga bagong write sa destinasyon: dapat mong pangalagaan o ipagkasundo ang data na iyon bago bumalik sa mas lumang kopya. Panatilihin ang source at backups para sa naaangkop na panahon ng recovery. Alisin ang lumang access at i-decommission ang mga resource lamang pagkatapos masuri ang destinasyon, backups, renewal at monitoring. Ang retention at pagtanggal ay dapat sumunod sa aktwal na patakaran ng serbisyo, hindi sa isang generic na nakapirming bilang ng oras. ## Mga tanong, nasagot ### Maaari ba akong direktang kopyahin ang isang live na file ng SQLite database? Huwag ipagpalagay na ang pagkopya ng isang file mula sa live na database ay gumagawa ng kumpleto at tuloy-tuloy na backup. Gumamit ng sinusuportahang paraan ng backup at isaalang-alang ang estado ng WAL. I-coordinate rin ang mga file na itinatago sa labas ng database. ### Ang pagbabago ba ng rekord ng DNS ay naglilipat ng data ng aking aplikasyon? Hindi. Ang DNS ay nagtuturo sa hinaharap na paglutas ng pangalan patungo sa isang address. Ang mga file ng aplikasyon, database, secret at background service ay nangangailangan ng hiwalay na proseso ng migration at beripikasyon. ### Maaari ba akong mangako ng zero downtime sa checklist na ito? Hindi. Ang downtime at consistency ay nakasalalay sa aplikasyon, trapiko, data at paraan ng cutover. Tinutulungan ka ng checklist na maghanda at sumubok ng kontroladong paglipat; hindi ito garantiya ng zero downtime. ## Hanapin ang gabay para sa iyong susunod na desisyon - [Sukatin ang destinasyon mula sa nasukat na pangangailangan]() - [Unawain ang kontrol ng guest at host]() - [Planuhin ang iyong self-hosted na workload]() - [Tuklasin ang mga resource ng VPS]() ## Opisyal na mga reperensya - [SQLite Online Backup API]() - [SQLite write-ahead logging]() - [curl manual: hostname resolution overrides]() - [ACME challenge types]() - [rsync manual]()