قائمة التحقق لترحيل VPS: النسخ الاحتياطية، DNS، TLS والرجوع
تسلسل ترحيل عملي لتطبيق مستضاف ذاتيًا: الجرد، والنسخ الاحتياطية المتسقة، ووجهة مُختبَرة، وكتابات خاضعة للتحكم، والتحويل عبر DNS، ومسار استعادة.
نظرة سريعة
يجرد ترحيل VPS الخاضع للتحكم الخدمات والبيانات، وينشئ نسخة احتياطية متسقة، ويتحقق من وجهة مستعادة، ويختبر اسم المضيف وتوجيه TLS، وينسّق الكتابات النهائية وDNS، ويحافظ على رجوع يراعي البيانات. لا تضمن أي قائمة تحقق وحدها توقفًا صفريًا.
اجرد التطبيق قبل نقله
اسرد الخدمات والإصدارات والمنافذ والمهام المجدولة وقواعد البيانات والملفات المرفوعة والإعدادات اللازمة لعمل التطبيق. حدد مكان حدوث الكتابات والخدمات الخارجية التي يعتمد عليها. نسخ دليل ويب ليس ترحيلًا كاملًا عندما تكون البيانات في مكان آخر.
سجّل أسماء DNS الحالية وسجلات IPv4 وIPv6 النشطة وطرق تجديد الشهادات ومسار وصول للاستعادة. احتفظ بالأسرار في أدوات النشر الخاصة بك. لا تضع كلمات المرور أو المفاتيح الخاصة أو تفريغات قاعدة البيانات في جذر مستند عام أو في قائمة تحقق ترحيل مشتركة.
أنشئ نسخة احتياطية متسقة وأثبت أنها تُستعاد
استخدم آلية النسخ الاحتياطي المدعومة من قاعدة البيانات بدلًا من نسخ ملفات عشوائية بينما تستمر الكتابات. بالنسبة إلى SQLite، ينشئ Online Backup API لقطة متسقة لقاعدة البيانات. في وضع WAL، يشارك ملف WAL في حالة قاعدة البيانات الدائمة، لذا قد يؤدي نسخ ملف قاعدة البيانات الرئيسي فقط إلى إغفال تغييرات تم تنفيذها.
النسخة الاحتياطية المتسقة لقاعدة البيانات ليست متسقة تلقائيًا مع التحميلات أو الطوابير أو الملفات المخزنة بشكل منفصل. نسّق التقاطها مع تطبيقك. استعد إلى موقع اختبار منفصل وتحقق من السجلات ومراجع الملفات وسلوك التطبيق قبل اعتبار النسخة الاحتياطية قابلة للاستخدام.
جهّز الوجهة قبل تغيير DNS
أنشئ المستخدمين والأذونات وإصدارات بيئة التشغيل والخدمات وأدلة التطبيق المقصودة على الخادم الجديد. استعد نسخة الاختبار إلى موقع بياناتها المقصود، خارج جذر الويب العام حيث يكون ذلك مناسبًا. تحقق من الملكية والوصول باستخدام حساب الخدمة الذي سيشغّل التطبيق فعليًا.
حافظ على المواقع غير ذات الصلة على خادم مشترك. استخدم جذر مستند ومضيفًا افتراضيًا وبيئة تشغيل مخصصة، وتحقق من إعداد خادم الويب وجهّز رجوعًا يستعيد فقط الملفات والإعدادات التي يملكها هذا التغيير.
اختبر اسم المضيف الفعلي والشهادة على الخادم الجديد
طلب متصفح إلى عنوان IP مجرد لا يعيد إنتاج التوجيه المستند إلى اسم المضيف أو التحقق من الشهادة. يسمح curl --resolve لاختبار باستخدام اسم المضيف المقصود وعنوان IP وجهة مختار مع الاحتفاظ باسم المضيف العادي وفحوص TLS. تحقق من حالة HTTP ومحتوى التطبيق المتوقع أيضًا. يستخدم المثال قيمًا مخصصة للتوثيق فقط؛ استبدلها بنطاقك ووجهتك المُتحقق منهما.
يجب أن توجد شهادة صالحة ومسار شبكة مسموح مسبقًا لنجاح ذلك الاختبار. لا تعطّل التحقق من الشهادة أبدًا لتعلن أن الترحيل جاهز. يمكن للتحقق من ACME المستند إلى DNS التحقق من نطاق دون تغيير عنوان خادم الويب الخاص به؛ أما التحقق المستند إلى HTTP فله متطلبات وصول مختلفة. اختبر التجديد بشكل منفصل عن الإصدار الأولي.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/اختر خطة للتحكم في الكتابة والمزامنة النهائية
حدد فترة صيانة قصيرة أو آلية اتساق أخرى مناسبة للتطبيق. أوقف أو أعد توجيه الكُتّاب الذين حددتهم، وخُذ النسخة الاحتياطية النهائية المتسقة لقاعدة البيانات، وزامن الملفات القابلة للتغيير المقابلة وتحقق من النتيجة. يمكن لعمال الطوابير وخطافات الويب ومهام cron أن تكتب حتى عندما تبدو الواجهة العامة هادئة.
استخدم تشغيلًا تجريبيًا قبل مزامنة الملفات. لا تضف أعلام الحذف أو تنسخ أدلة النظام بأكملها كطريق مختصر. حافظ على إمكانية استعادة الخدمة القديمة حتى تتحقق من التطبيق الجديد وتحدد الموقع الموثوق للكتابات.
غيّر DNS، ثم راقب عائلتي العناوين
حدّث السجلات المطلوبة للخدمة وخُذ في الحسبان ذاكرات التخزين المؤقت الموجودة للمحلل. تحقق من الإجابات الموثوقة وعدة مسارات عملاء عادية. إذا بقي سجل AAAA قديم نشطًا، فقد يستمر عملاء IPv6 في الوصول إلى الخادم القديم بينما يصل عملاء IPv4 إلى الجديد.
اختبر تسجيل الدخول والقراءات والكتابات والتحميلات والمهام الخلفية والاستدعاءات الخارجية على الخدمة الجديدة. تجنب تشغيل نسختين مستقلتين قابلتين للكتابة من التطبيق نفسه خلال الانتقال. حافظ على قاعدة واضحة للتعامل مع حركة البيانات التي لا تزال تصل إلى الوجهة القديمة.
اجعل الرجوع قرارًا يتعلق بالبيانات وكذلك قرارًا يتعلق بـ DNS
حدد شروط الفشل التي تطلق الرجوع ومن يتحكم في التحويل. إعادة DNS وحدها ليست كافية بعد وصول كتابات جديدة إلى الوجهة: يجب الحفاظ على تلك البيانات أو التوفيق بينها قبل العودة إلى نسخة أقدم.
احتفظ بالمصدر والنسخ الاحتياطية لفترة استعادة مناسبة. أزل الوصول القديم وأوقف الموارد فقط بعد التحقق من الوجهة والنسخ الاحتياطية والتجديد والمراقبة. يجب أن يتبع الاحتفاظ والحذف سياسة الخدمة الفعلية، لا عدد ساعات ثابتًا عامًا.