هیچکس یک سایت زنده را برای سرگرمی جابهجا نمیکند. این کار وقتی اتفاق میافتد که هاست فعلی ناگهان یک عکس از پاسپورتتان بخواهد، یا یک شکایت را با مهلت بیستوچهار ساعته برایتان بفرستد، یا کشوری که دیتاسنترش در آن قرار دارد دیگر جای معقولی برای نگهداری دادههایتان بهنظر نرسد. هرچه شما را به این کار وادار کرده باشد، خودِ جابهجایی بخش خطرناک ماجراست — همان یک لحظهای است که سایت میتواند خاموش شود، و همان یک لحظهای است که یک قدم بیاحتیاطی میتواند سرور جدید را به همان هویتی میخکوب کند که میخواستید پشت سر بگذارید.
هر دو ریسک یک درمان دارند، و آن درمان یک ابزار نیست. ترتیب است. مهاجرتی که با توالی درست اجرا شود هیچ پنجرهای ندارد که در آن سایت در دسترس نباشد، چون هر دو سرور همزمان زندهاند و DNS آخرین چیزی است که جابهجا میشود. مهاجرتی که با توالی نادرست اجرا شود، همزمان یک قطعی و یک رد بهجا میگذارد. آنچه در ادامه میآید همان توالی است، نوشتهشده برای کسی که به یک هاست آفشور و بدون KYC میرود، نه کسی که بین دو ارائهدهنده معروف جابهجا میشود — مکانیزم یکسان است، اما پاکسازی بعد از آن یکسان نیست.
معنای واقعی «قطعی صفر»
این عبارت اغلب شل و بیدقت بهکار میرود، و دقیقاً همین بیدقتی جایی است که آدم را گرفتار میکند. سرو کردن HTTP از دو دستگاه همزمان کار سادهای است. سازگار نگهداشتن حالت (state) وقتی دو دستگاه همزمان سرو میکنند، بخش سخت ماجراست، و تنها بخشی است که تا به حال داده از دست داده. پس پیش از برنامهریزی برای هر چیزی، مشخص کنید واقعاً کدامیک از اینها را دارید اجرا میکنید، چون همین جواب شکل کل آن شب را تعیین میکند.
| چه چیزی را جابهجا میکنید | بخشی که واقعاً گیر میکند | برنامه درست چیست |
|---|---|---|
| سایت استاتیک، سایت بروشوری، خروجی تولیدشده | هیچچیز. حالتی وجود ندارد که دو نیم شود | کپی کنید، تأیید کنید، جابهجا کنید. واقعاً قطعی صفر |
| یک CMS با پایگاهداده — WordPress، Ghost، یک انجمن | کامنتها، ورودها و پستهایی که همزمان روی دو پایگاهداده مینشینند | یک توقف فقطخواندنی که با دقیقه سنجیده میشود، در خلوتترین ساعت شما |
| یک فروشگاه، یا هر چیزی که سفارش میگیرد | یک اسپلیتبرین، سفارشهای پرداختشده را بیصدا از دست میدهد | پنجره تعمیر کوتاه را بپذیرید. از تطبیق دوباره حسابها ارزانتر است |
| هر چیزی با کرونجاب یا ورکر پسزمینه | یک وظیفه یکسان روی هر دو سرور اجرا میشود — ایمیل دوبل، پرداخت دوبل | زمانبندی را روی سرور قدیم پیش از شروع سرور جدید غیرفعال کنید |
| ایمیل روی همان دامنه | رکوردهای MX طبق ساعت خودشان از کشها منقضی میشوند، بیربط به رکورد A شما | ایمیل را در شبی جدا جابهجا کنید، و MX قدیم را یک هفته فعال نگه دارید |
توجه کنید که فقط ردیف اول واقعاً رایگان است. در همهجای دیگر، «قطعی صفر» یعنی «توقف نوشتنی آنقدر کوتاه که هیچکس برایش تیکت نمیزند». دو دقیقه فقطخواندنی در ساعت 04:00 یک خطای گردکردن است؛ دو ساعت نوشتن دوپاره روی دو پایگاهداده، یک آخر هفته کامل تطبیق حساب میشود. توقف نوشتن را انتخاب کنید.
TTL رکورد DNS را چند روز پیش از جابهجایی پایین بیاورید
این تنها گامی است که زمان انتظار دارد، و دقیقاً به همین دلیل هم اول آمده و هم همان گامی است که بیشتر افراد از آن رد میشوند. TTL شما — زمان ماندگاری — به هر ریزالوری در اینترنت میگوید تا چه مدت مجاز است رکورد شما را کش کند پیش از آنکه دوباره بپرسد. اگر رکورد A شما TTLای برابر با 86400 داشته باشد، ریزالوری که یک ساعت پیش آن را جستوجو کرده، تا بیستوسه ساعت دیگر همان IP قدیمی را تحویل میدهد، مهم نیست در ریجیستار چه چیزی را تغییر داده باشید.
نکته حیاتی این است که پایینآوردن TTL خودش تابع همان TTL قدیمی است. ریزالورها فقط وقتی از مقدار جدید و کوتاهتر باخبر میشوند که نسخه کششده قدیمی منقضی شود. پس TTL را دستکم یک دوره کامل TTL قدیمی پیش از جابهجایی نهایی به 300 ثانیه کاهش دهید — با یک TTL یکروزه، یعنی این کار را 24 تا 48 ساعت زودتر انجام دهید. آنوقت کل اینترنت ظرف پنج دقیقه از تغییر، به رکورد جدید شما همگرا میشود، و جابهجایی نهایی دیگر یک رویداد پرتعلیق نیست.
چند روز بعد از جابهجایی، TTL را به مقداری معقول برگردانید. TTL سیصد ثانیهای ابزار خوبی است اما تنظیم دائمی بدی است: حجم کوئریهایتان را چند برابر میکند و ارائهدهنده DNS شما را به یک نقطه شکست تک بسیار حساستر تبدیل میکند.
فهرستبرداری از آنچه جابهجا میکنید، نه آنچه بهخاطر دارید
هر مهاجرت شکستخوردهای همان کالبدشکافی را دارد: چیزی که هیچکس فهرستش نکرده بود، کپی نشده. ریشه وب (web root) و پایگاهداده آن دو چیزی هستند که همه بهخاطر میآورند؛ فهرست زیر بقیه ماجراست، و ارزشش را دارد که آن را واقعاً قدمبهقدم طی کنید، نه از روی حافظه.
- کارهای زمانبندیشده.
crontab -lبرای هر کاربر، بهعلاوه تایمرهای systemd. هوکهای تمدید و کارهای شبانه اینجا پنهان میشوند. - تعریفهای سرویس. واحدهای سفارشی systemd، vhostهای وبسرور، poolهای PHP-FPM، هر پیکربندی supervisor.
- اسرار و محیط. فایلهای
.env، کلیدهای API، پسوردهای پایگاهداده، سالتهای اپلیکیشن — و توجه کنید که اینها باید چرخانده شوند، نه فقط کپی. - مواد TLS. گواهیها و، مهمتر از آن، حساب ACME و پیکربندی تمدید.
- هویت ایمیل. کلیدهای خصوصی DKIM، رکوردهای SPF و DMARC. عدم تطابق اینجا با سروصدا خراب نمیشود؛ فقط بیصدا ایمیل شما را به اسپم میفرستد.
- رسانههای آپلودشده. اغلب بیرون از ریشه وب، اغلب بزرگترین دارایی شما.
- هر چیز بیرونی که به IP شما اعتماد میکند. allowlistهای درگاه پرداخت، مقصدهای webhook، فایروالهای پایگاهداده، APIهای شخص ثالث با محدودیت IP. این، رایجترین دلیل شنیدن جمله «سایت کار میکند اما تسویهحساب خراب است» در ساعت 03:00 است.
- فهرست پکیجها.
dpkg --get-selectionsیا معادلش، تا دستگاه جدید همان اکستنشنها و کتابخانهها را داشته باشد، نه چیزی نزدیک به آنها.
پیش از شروع کپی، فهرست را یادداشت کنید. این فهرست بعداً طرح تستتان هم هست — هر خط آن چیزی است که باید روی سرور جدید تأیید شود، پیش از آنکه DNS از وجودش خبردار شود.
اول سرور جدید را بسازید، و پیش از آنکه چیزی رویش باشد سختسازیاش کنید
مقصد را زود سفارش دهید و بگذارید یکی دو روز خالی روشن بماند. همپوشانی هیچ هزینهای ندارد — یک VPS آفشور کوچک چند دلار در ماه است — و ارزش زیادی دارد که ساخت آن را زیر فشار زمانی و با یک پایگاهداده منجمدشده که منتظر است، انجام ندهید.
محیط قدیم را عمداً مطابقت دهید: همان توزیع و همان نسخه اصلی، همان نسخه اصلی PHP یا Node یا Python، همان نسخه اصلی پایگاهداده. وسوسه مدرنسازی درست همان لحظه که آنجایید بسیار زیاد است و باید کاملاً در برابرش مقاومت کنید. اگر سایت بعد از جابهجایی نهایی خراب شود، میخواهید دقیقاً یک متغیر تغییر کرده باشد. استک را دو هفته بعد، در یک بعدازظهر معمولی، با امکان بازگشت، ارتقا دهید.
وقتی هنوز خالی است سختسازیاش کنید. SSH فقط با کلید، فایروالی با سیاست پیشفرض رد، بهروزرسانیهای امنیتی خودکار — چکلیست سختسازی ساعت اول دقیقاً همین فهرست است، و روی دستگاهی که هیچچیز رویش نیست، اعمالکردنش خیلی سادهتر است. اگر داده آنقدر حساس است که بهخاطرش دارید حوزه قضایی عوض میکنید، همین هم لحظه درستی است برای تصمیمگیری درباره رمزنگاری کامل دیسک، چون بعداً اضافهکردنش یعنی یک مهاجرت دیگر.
داده را دوبار کپی کنید: یک پاس کند، بعد یک پاس سریع
غریزه این است که همهچیز را در پنجره تعمیر کپی کنید. برعکسش را انجام دهید. چند روز زودتر، وقتی سایت قدیم با خیال راحت دارد ترافیک سرو میکند، یک کپی کامل بگیرید، بعد در لحظه جابهجایی نهایی یک پاس دوم بزنید که فقط چیزهایی را جابهجا میکند که تغییر کردهاند. پاس اول میتواند شش ساعت طول بکشد و هیچکس متوجه نمیشود. پاس دوم نود ثانیه طول میکشد، و این دقیقاً کل بودجه قطعی شماست.
برای فایلها، rsync -aHAX --numeric-ids مجوزها، مالکیت، هاردلینکها و ویژگیهای گسترده (extended attributes) را حفظ میکند؛ فلگ --numeric-ids مهم است چون UIDها بهندرت بین دو دستگاه تازهساخته با هم میخوانند. یکبار زود اجرایش کنید، بعد بلافاصله پیش از جابهجایی نهایی، با همان آرگومانها دوباره اجرایش کنید — اجرای دوم فقط دلتا را منتقل میکند.
پایگاهدادهها به همان رفتار دومرحلهای نیاز دارند اما با ابزارهای متفاوت. یک mysqldump --single-transaction یا pg_dump یک اسنپشات اولیه سازگار به شما میدهد که رویش بسازید و تست کنید. در لحظه جابهجایی نهایی، یا در طول توقف کوتاه نوشتن یک دامپ دوم بگیرید، یا — برای یک پایگاهداده بزرگ که حتی یک توقف کوتاه هم دردسرساز است — سرور جدید را روزها زودتر بهعنوان یک ریپلیکا از سرور قدیم راهاندازی کنید، بگذارید بهروز شود، بعد ترفیعش دهید. تکرارسازی توقف را به چند ثانیه تبدیل میکند. همچنین یک مهاجرت دوساعته را به یک پروژه دوروزه تبدیل میکند، پس فقط وقتی از آن استفاده کنید که اندازه داده واقعاً آن را ایجاب کند.
پول کنید، نه پوش، و هرگز از مسیر لپتاپ خودتان. کپی را از سرور جدید آغاز کنید تا انتقال با سرعت دیتاسنتر و مستقیم بین دو هاست انجام شود. عبوردادن گیگابایتها از اتصال خانگیتان کند است، و IP مسکونی شما را در لاگهای دسترسی هر دو دستگاه ثبت میکند — دقیقاً همان پیوندی که یک مهاجرت با انگیزه حریم خصوصی برای اجتنابش وجود دارد. اگر حتی باخبرشدن هاست قدیم از IP جدیدتان هم غیرقابلقبول است، اصلاً مستقیم کپی نکنید: در عوض سرور جدید را از بکاپ رمزنگاریشده خارج از محل خودتان بازیابی کنید، و آنوقت این دو دستگاه هرگز با هم حرف نمیزنند.
پیش از آنکه DNS از وجودش خبردار شود، سرور جدید را تست کنید
میتوانید هاستنیم واقعی را از IP جدید سرو کنید بدون آنکه حتی یک رکورد عمومی را تغییر دهید، و باید هم همین کار را بکنید — همین چیزی است که جابهجایی نهایی را بیحادثه میکند. یک خط به فایل /etc/hosts محلیتان اضافه کنید که دامنه را به IP جدید اشاره دهد، یا از آن رد شوید و بگذارید curl همین کار را فقط برای یک درخواست انجام دهد:
curl -I --resolve example.com:443:203.0.113.10 https://example.com/
حالا فهرست را قدمبهقدم طی کنید. صفحه اول و سه صفحه عمیق را بارگذاری کنید. وارد شوید. یک فرم را ارسال کنید. یک فایل آپلود کنید. بررسی کنید که اتصال پایگاهداده همان اتصال محلی جدید است، نه اینکه هنوز از روی اینترنت به هاست قدیم اشاره داشته باشد — اشتباهی که تا وقتی سرور قدیم را کنسل نکنید کاملاً درست کار میکند. کرونجابها را دستی اجرا کنید و خروجیشان را بخوانید. ریدایرکتها را تأیید کنید و اینکه یک URL ناموجود هنوز 404 برمیگرداند، نه 200.
گواهی TLS را همین حالا صادر کنید، پیش از جابهجایی نهایی، نه بعد از آن. از چالش DNS-01 استفاده کنید، که کنترل دامنه را از طریق یک رکورد TXT ثابت میکند و به همین دلیل، حتی وقتی رکورد A هنوز به سرور قدیم اشاره دارد هم کار میکند. اگر برای اعتبارسنجی HTTP-01 بعد از تغییر DNS صبر کنید، هر بازدیدکننده زودهنگام در طول این شکاف یک هشدار گواهی میگیرد — یک قطعی خودخواسته درست در همان پنجرهای که میخواستید محافظتش کنید.
جابهجایی نهایی، بهترتیب
تا اینجا سرور جدید ساخته شده، سختسازی شده، پر شده، زیر هاستنیم واقعی تست شده و یک گواهی معتبر دارد. خودِ جابهجایی نهایی حالا یک فهرست کوتاه و کسلکننده است، و هدف هم دقیقاً همین است.
- اگر کس دیگری به سایت وابسته است، پنجره کار را اعلام کنید، بعد سایت قدیم را به حالت فقطخواندنی یا تعمیر و نگهداری ببرید.
- کرون و ورکرهای پسزمینه را روی هاست قدیم غیرفعال کنید. این کار را پیش از راهانداختنشان روی سرور جدید بکنید، هرگز بعدش.
- پاس دلتای نهایی
rsyncو دامپ نهایی پایگاهداده را بگیرید، و آن را ایمپورت کنید. - اپلیکیشن را روی سرور جدید بالا بیاورید و تستهای اولیه خود را از طریق
--resolve، روی داده نهایی، دوباره اجرا کنید. - رکوردهای A و AAAA را به IP جدید تغییر دهید. با TTL سیصد ثانیهای، کل اینترنت ظرف پنج دقیقه دنبال میکند.
- کرون و ورکرها را روی هاست جدید فعال کنید.
- هر دو لاگ دسترسی را کنار هم تماشا کنید. ترافیک از سرور قدیم خالی میشود و روی سرور جدید ظاهر میشود؛ وقتی سرور قدیم ساکت شد، جابهجایی نهایی کامل است.
- سرور قدیم را یک هفته روشن، در حال سرویسدهی و دستنخورده رها کنید. این همان مسیر بازگشت شماست.
قدم هشتم همان قدمی است که افراد حذفش میکنند، و ارزانترین بیمه کل این فهرست است. به قیمت چند دلار، توانایی برگرداندن DNS به عقب را — یک بازیابی پنجدقیقهای — تا هر وقت که برای اطمینان لازم باشد، نگه میدارید.
آنچه مهاجرت از خود بهجا میگذارد
اینجا همان بخشی است که راهنماهای عمومی مهاجرت از قلم میاندازند، و بخشی است که اگر برای حریم خصوصی جابهجا شدهاید نه برای قیمت، از همه بیشتر اهمیت دارد. جابهجایی یک سایت، تاریخچهاش را پاک نمیکند. چندین رکورد عمومی و نیمهعمومی از چیدمان قدیمی برای همیشه از این جابهجایی جان سالم بهدر میبرند، و دانستن اینکه کدامها هستند، فرق بین یک قطع رابطه واقعی و یک حس دروغین از آن است.
| چه چیزی این جابهجایی را ثبت میکند | چه کسی میتواند آن را بخواند | واقعاً چه کاری از دستتان برمیآید |
|---|---|---|
| Passive DNS — رکوردهای A تاریخی | هرکسی، از طریق سرویسهای تجاری تاریخچه | هیچکاری. IP قدیمی برای همیشه به این نام مرتبط میماند. طوری برنامهریزی کنید که انگار عمومی است، چون هست |
| لاگهای Certificate Transparency | هرکسی، برای همیشه، قابل جستوجو بر اساس دامنه | هر گواهیای که تا بهحال صادر شده فهرست میشود — از جمله زیردامنههایی که بهنظر داخلی میرسیدند و فراموششان کرده بودید. یک wildcard را به نامهای توصیفی ترجیح دهید |
| رکوردهای حساب هاست قدیم | هاست قدیم، و هرکسی که بتواند مجبورشان کند | جزئیات کارت، ایمیل ثبتنام، IPهای ورود. یک مقصد بدون KYC از آینده محافظت میکند، نه از گذشته |
| تاریخچه WHOIS | آرشیوهای تجاری تاریخچه WHOIS | اگر دامنه حتی یکبار با جزئیات واقعی ثبت شده باشد، همان لحظه ضبط شده است. حریم خصوصیای که بعداً اعمال شود آن را پس نمیگیرد |
| شناسههای آنالیتیکس و تبلیغات | فروشنده ابزار، و هرکسی که سورس صفحه شما را بخواند | حمل همان شناسه ردیابی، دو سایت را بهشکلی قطعی به هم پیوند میدهد. یکی جدید صادر کنید، یا کلاً کنارش بگذارید |
| دامپها و بکاپهای جامانده روی دیسک قدیم | هرکسی که بعداً آن فضای ذخیرهسازی به او تخصیص داده شود | پیش از کنسلکردن، حذف و رونویسی کنید. روی ذخیرهسازی اشتراکی، فرض کنید حذف فقط یک اشاره است، نه یک تضمین |
هدرهای Received: در ایمیلهای ارسالی | هر گیرنده، برای همیشه | هیچچیز عطفبهماسبق. فقط ایمیلهایی که بعد از جابهجایی میفرستید، مسیر جدید را حمل میکنند |
| اتصالهای خودتان در طول کپی | ISP شما، و لاگهای دسترسی هر دو هاست | این یکی کاملاً دست خودتان است. هرگز از IPای که هویتتان را نشان میدهد، به هیچکدام از دو دستگاه دست نزنید |
خلاصه صادقانه این است که یک مهاجرت نمیتواند گذشته را بازنویسی کند — فقط میتواند جلوی افزودهشدن به آن را بگیرد. این هنوز ارزش زیادی دارد، اما تصمیم را تغییر میدهد: اگر مدل تهدید شما ایجاب میکند که هیچ ناظری نتواند سایت جدید را به سایت قدیم پیوند بزند، جابهجایی همان دامنه به یک هاست جدید این هدف را برآورده نمیکند، و هیچمقدار دقت در طول جابهجایی نهایی هم این را عوض نمیکند. آن حالت به یک نام جدید و یک شروع تمیز نیاز دارد، که در ادامه دربارهاش صحبت میکنیم. اما اگر هدفتان این است که از امروز به بعد جلوی تولید رکوردهای شناساییکننده را بگیرید، و مرکز ثقل حقوقیتان را به حوزه قضاییای که خودتان انتخاب کردهاید ببرید، این جابهجایی دقیقاً همین کار را میکند. راهنمای OpSec سرور ما، عادتهایی را پوشش میدهد که بعد از آن همهچیز را تمیز نگه میدارند.
مسئله دامنه: با خودتان ببرید یا از نو شروع کنید؟
سایت و دامنه دو تصمیم مستقلاند، و قاطیکردنشان با هم رایج است. میتوانید هاستینگ را همین امروز جابهجا کنید و ریجیستار را برای همیشه دستنخورده رها کنید؛ هیچچیز در تغییر سرور شما را مجبور نمیکند به دامنه دست بزنید. اینکه آیا باید این کار را بکنید یا نه، کاملاً به این بستگی دارد که دامنه از قبل چه چیزی درباره شما میداند.
- دامنه را نگه دارید، ریجیستار را عوض کنید. وقتی دامنه ارزش دارد منطقی است — لینکها، رتبهها، نامی که مردم تایپ میکنند. این کار آینده رکورد WHOIS را درست میکند، نه تاریخچهاش را، و همه سیگنالهای رتبهبندی را دستنخورده نگه میدارد. این جواب درست برای بیشتر سایتهای تجاری است.
- دامنه را نگه دارید، هیچچیز جز هاست را عوض نکنید. وقتی بهخاطر حوزه قضایی، آپتایم یا موضع DMCA جابهجا شدهاید، نه گمنامی، کاملاً معقول است. سادهترین جابهجایی ممکن، با ریسک سئوی صفر.
- دامنه جدید، ریدایرکت به قدیمی. رتبهها را حفظ میکند، و دو نام را بهشکلی عمومی و دائمی به هم پیوند میدهد. این را برای تداوم انتخاب کنید، هرگز برای حریم خصوصی — چون خودِ ریدایرکت همان پیوند است.
- دامنه جدید، قطع تمیز. تنها گزینهای که واقعاً این پیوند را قطع میکند، و هر رتبه و لینک ورودیای را که داشتید از شما میگیرد. از همان اول آن را بهشکل خصوصی ثبت کنید، چون یک دامنه فقط بهاندازه اولین ثبتش ناشناس است. راهنمای ما درباره ثبت ناشناس دامنه با ارز دیجیتال نحوه انجام درست این کار را پوشش میدهد.
عمداً انتخاب کنید، و پیش از جابهجایی نهایی این کار را بکنید، نه در حینش. تغییر نظر درباره دامنه بعد از جابهجایی DNS یعنی انجام بخش ظریف کار برای بار دوم.
سرور قدیم را بهدرستی از رده خارج کنید
یکی دو هفته بعد از جابهجایی نهایی، وقتی لاگهای سرور جدید کسلکنندهاند و لاگهای سرور قدیم خالیاند، وقتش است حساب قدیم را ببندید. این کار را به همین ترتیب انجام دهید، چون میانبر وسوسهانگیز — زدن دکمه کنسل — همان چیزی است که داده شما را روی دیسک یک نفر دیگر جا میگذارد.
- مطمئن شوید هیچچیز دیگر به IP قدیم اشاره نمیکند: آدرسهای هاردکدشده در webhookهای شخص ثالث، allowlistها، مانیتورینگ، و هر رکورد DNSای که فراموش کرده بودید را بررسی کنید، مثل یک زیردامنه ولگرد
mailیاcpanel. - هر رازی که تا بهحال روی آن دستگاه زندگی کرده را بچرخانید — پسوردهای پایگاهداده، کلیدهای API، سالتهای اپلیکیشن، کلیدهای DKIM، کلیدهای SSH. آنها را به جلو کپی نکنید.
- کلیدهای عمومی SSH خودتان و هر دسترسی پشتیبانی را از سرور قدیم حذف کنید.
- اپلیکیشن، دامپها و بکاپها را حذف کنید، بعد فضای آزاد را رونویسی کنید تا یک خواندن سرسری از ولوم بازیافتی چیزی بهدست ندهد.
- فقط بعد از آن سرویس را خاتمه دهید، و هر روش پرداخت ذخیرهشده را از حساب قدیم حذف کنید.
هر چیزی که روی سختافزاری زندگی کرده که دیگر کنترلش دست شما نیست، طبق تعریف لو رفته است. نه به این دلیل که هاست قدیم شما بدخواه است، بلکه چون آن دیسک دارد به یک استخر ذخیرهسازی برمیگردد و شما هرگز نمیفهمید چه چیزی از پاکسازی جان سالم بهدر برده. چرخاندن یک پسورد پایگاهداده دو دقیقه طول میکشد. ماهها بعد کشفکردن اینکه یک کلید از یک سرور ازردهخارجشده هنوز چیزی را باز میکند، بسیار بیشتر طول میکشد.
کل توالی، در یک صفحه
استدلالها را کنار بگذارید، یک مهاجرت هاست نه قدم است، که فقط دوتای آنها فوریت دارند:
- دو روز زودتر: TTL رکورد DNS را به 300 ثانیه کاهش دهید.
- دو روز زودتر: سرور مقصد را سفارش دهید و سختسازی کنید، نسخهبهنسخه مطابق با استک قدیم.
- روزها زودتر: فهرست را بنویسید — کرون، اسرار، TLS، کلیدهای ایمیل، رسانه، allowlistهای IP، پکیجها.
- روزها زودتر: اولین کپی کامل داده را، مستقیم بین دو هاست، انجام دهید.
- پیش از پنجره: گواهی را با DNS-01 صادر کنید و همهچیز را از طریق
--resolveتست کنید. - پنجره (چند دقیقه): نوشتن را متوقف کنید، کرون قدیم را غیرفعال کنید، کپی دلتا و دامپ نهایی را بگیرید، اپ جدید را بالا بیاورید.
- پنجره (چند ثانیه): رکورد A را تغییر دهید، بعد کرون را روی هاست جدید فعال کنید.
- هفته بعد: سرور قدیم را بهعنوان مسیر بازگشت زنده نگه دارید، هر دو فایل لاگ را تماشا کنید، بعد TTL را دوباره بالا ببرید.
- بعد از آن: اسرار را بچرخانید، پاکسازی کنید، کنسل کنید — و بهخاطر داشته باشید این جابهجایی چه چیزی را نتوانست پاک کند.
هیچچیز در این فهرست سخت نیست. هر قدمی که درد دارد، قدمی است که بیترتیب انجام شده — یک TTL که همان شب کاهش داده شده، گواهیای که بعد از تغییر DNS صادر شده، یک کرونجاب که روی دستگاهی که دیگر مرجع نیست فعال مانده. توالی را درست انجام دهید و بخش جالب یک مهاجرت این میشود که کجا سرور را قرار دهید، نه خودِ جابهجایی. اگر هنوز این را مشخص نکردهاید، راهنمای انتخاب حوزه قضایی جای خوبی برای شروع است.