تعديل قاعدة البيانات داخل نسخة احتياطية لإزالة وسم مفتاح مكرر لتجنب الفشل عند الاستعادة

هذا المنشور هو نسخة مكثفة جدًا من آخر 24 ساعة لدي، على الرغم من أنه لم ينجح بعد، لذا آمل أيضًا أن ينشر شخص ما أين أخطأت أدناه.

فشل تحديث Discourse الخاص بي بسبب مفتاح مكرر، حيث تم تكرار إحدى علاماتي. لإصلاح مشكلة التحديث، احتجت إلى إجراء تثبيت جديد لـ Discourse ثم تحميل أحدث نسخة احتياطية لدي، لكن إعادة التحميل تفشل لأنها ترفض المفتاح المكرر. لذلك احتجت إلى الدخول إلى النسخة الاحتياطية لتعديل العلامة المخالفة إلى شيء آخر.

لسبب ما، فإن النسخة الاحتياطية المعاد ضغطها مع مشكلة العلامة المكررة التي تم إصلاحها أصغر بكثير من النسخة الاحتياطية التي جاءت منها، وتفشل عندما أحاول استعادتها، لذلك حدث خطأ ما في عملية إعادة الضغط.

1) تحديد موقع النسخ الاحتياطية: لتحديد موقع النسخ الاحتياطية لـ Discourse، يمكنك استخدام الأمر التالي:

sudo find / -name "*.tar.gz"

سيؤدي هذا إلى البحث في نظامك عن جميع ملفات النسخ الاحتياطي بالامتداد “.tar.gz”. افتراضيًا، يجب أن يكون داخل حاويتك في: shared/backups/default

2) إنشاء نسخة: بمجرد العثور على النسخة الاحتياطية التي تريد العمل معها، قم بإنشاء نسخة منها لضمان أن لديك نسخة احتياطية من الملف الأصلي. استخدم الأمر “cp”:

bash

sudo cp /path/to/original_backup.tar.gz /path/to/copy_backup.tar.gz

3) استخراج النسخة: استخرج محتويات ملف النسخة الاحتياطية المنسوخ باستخدام الأمر “tar”:

bash

tar -xzvf /path/to/copy_backup.tar.gz

سيؤدي هذا إلى استخراج ملفات النسخ الاحتياطي إلى دليل مؤقت.

4) تعديل العلامات في قاعدة البيانات: انتقل إلى ملفات النسخ الاحتياطي المستخرجة وافتح ملف قاعدة البيانات ذي الصلة باستخدام محرر نصوص. واجهت مشكلة مع علامات “socialmedia” المكررة، والتي منعت الاستعادة الناجحة. في قاعدة بيانات كبيرة، هناك العديد من الحالات للعلامات، ومن المحتمل أن تكون العلامة المحددة التي تبحث عنها، لذا بحثت عن ‘immutable socialmedia’ باستخدام Ctrl W في Nano، مما أدى بي إلى هناك مباشرة.

sudo nano /path/to/extracted_database.sql

قمت بتعديل إحدى حالات علامة “socialmedia” إلى “socialmedia2”، ثم أجريت بحثًا سريعًا للتحقق من أنها تظهر مرة واحدة فقط الآن. يمكنني إصلاح تلك العلامات من قسم المسؤول بمجرد نجاح الاستعادة.

5) إعادة الضغط: بعد تعديل ملفات النسخ الاحتياطي، قم بإنشاء ملف نسخ احتياطي جديد بالمحتوى المصحح. استخدم الأمر التالي لضغط الملفات المعدلة:

tar -czvf /path/to/new_modified_backup.tar.gz /path/to/modified_files_directory

6) نقل إلى الملف الصحيح: انقل ملف النسخ الاحتياطي الجديد المعدل إلى الدليل المناسب حيث يتم تخزين النسخ الاحتياطية. الموقع الافتراضي هو عادةً “/shared/backups/default”:

sudo mv /path/to/new_modified_backup.tar.gz /shared/backups/default/

7) إيقاف وبدء الخدمات: قبل استعادة النسخة الاحتياطية المعدلة، تأكد من إيقاف الخدمات ذات الصلة لتجنب التعارضات المحتملة أثناء عملية الاستعادة. استخدم الأمر “./launcher stop app” لإيقاف تطبيق Discourse:

./launcher stop app

8) استعادة النسخة الاحتياطية: للاستعادة من النسخة الاحتياطية المعدلة، استخدم الأمر “discourse restore” مع المسار إلى ملف النسخ الاحتياطي الجديد:

discourse restore /shared/backups/default/new_modified_backup.tar.gz

أو يمكنك القيام بذلك عبر /admin على موقعك حيث يجب أن تظهر الآن في قسم النسخ الاحتياطية.

9) التحقق من الاستعادة: بعد اكتمال عملية الاستعادة، تحققت من نجاح التغييرات عن طريق فحص تطبيق Discourse وقاعدة البيانات للتأكد من إزالة علامات “socialmedia” المكررة.

10) بدء الخدمات: قمت بإعادة تشغيل الخدمات التي تم إيقافها سابقًا لإعادة تشغيل تطبيق Discourse. استخدمت الأمر “./launcher start app” لبدء تشغيل تطبيق Discourse:

./launcher start app

11) حذف الملفات المؤقتة والنسخ الاحتياطية الإضافية: بعد استعادة النسخة الاحتياطية بنجاح، قمت بحذف أي ملفات مؤقتة ونسخ احتياطية إضافية تم إنشاؤها أثناء العملية لتحرير مساحة القرص. استخدم الأمر “rm” لإزالة الملفات:

sudo rm -r /path/to/temporary_directory
sudo rm /path/to/copy_backup.tar.gz
3 إعجابات

لماذا؟
لماذا لم تتمكن من إصلاح هذا “عبر الإنترنت” عن طريق إعادة تشغيل التطبيق، والدخول إلى الحاوية، والدخول إلى postgres ثم التعامل مع إدخال البيانات على الفور؟

إعجاب واحد (1)

لم أتوقع الخطأ، لذا كنت قد وضعت بالفعل الإصدار الجديد من Discourse على الخادم الخاص بي. كان خطأ المفتاح المكرر موجودًا في النسخة الاحتياطية وليس في التطبيق المثبت حديثًا، لكن لم يكن بإمكاني استعادة النسخة الاحتياطية لأنها كانت تتطلب إصلاح الخطأ أولاً.

لذلك اضطررت إلى محاولة تعديل العلامة داخل النسخة الاحتياطية.

ولكنك رأيت الخطأ عند التحديث؟
في المرة القادمة اجعل حياتك أسهل وقم بالإصلاح في مكانه.

لم يكن التطبيق قيد التشغيل ولم أتمكن من إعادة تحميله، لذلك قمت بالتحديث إلى إصدار Discourse جديد في محاولة لحل هذه المشكلة. مما يعني أنه لم يكن لدي وصول إلى قاعدة البيانات في أي مكان آخر غير النسخة الاحتياطية.

من المؤكد أن هذه حالة متخصصة نشرتها هنا، وكان الخيار الأفضل هو ملاحظة المشكلة وحلها بينما كان لا يزال لدي وصول مباشر إلى قاعدة بيانات التطبيق، لكنني فاتتها ولم أتمكن من العثور على أي خيار آخر.

إعجاب واحد (1)

لا تقلق. على الأقل لقد أظهرت أنه ممكن، وتعلمت بعض الأشياء الجديدة ومنحت الآخرين خيارًا إضافيًا.
عمل جيد! :clap:

3 إعجابات

شكرًا، على الرغم من أن الملف الأصلي كان 128 ميجابايت والملف الجديد 29 ميجابايت، لذلك أعتقد أن إعادة ضغط الملف على الخادم قد تكون قد اقتطعت الملف بسبب طوله.

تبدو هذه العملية وكأنها يجب أن تنجح، ولكن الملف الذي انتهى بي الأمر به لم يكن من الممكن استخدامه لاستعادة خطابي.

إعجاب واحد (1)

كان المسار الذي سلكته أكثر خطورة ولكنه بالتأكيد قابل للتنفيذ؟ ربما يمكن لشخص ما أن يقدم بعض النصائح حول هذه المسألة.
يمكنك على الأرجح تكرار هذا مرة أخرى من النسخ الاحتياطي لذلك …

إعجاب واحد (1)

هل تم حل هذه المشكلة؟ يبدو الأمر وكأنه دليل إرشادي، ولكن يبدو أن موقعك لا يزال معطلاً.

ربما تفعل شيئًا لا أفهمه، ولكن عادةً يمكنك فقط تشغيل ./launcher start app لبدء الحاوية القديمة، هل كان هناك سبب لعدم قدرتك على القيام بذلك؟

بعد ذلك، يمكنك استخدام أدوات Rails أو SQL لإصلاح قاعدة البيانات الخاصة بك في الحاوية القديمة، ثم محاولة تشغيل إعادة البناء/الاستعادة مرة أخرى.

أو ربما قمت بترحيل قاعدة البيانات إلى ما هو أبعد مما يمكن أن تتعامل معه الحاوية القديمة.

لقد قمت بإجراء جراحة مماثلة على نسخة احتياطية من قبل عندما كان الموقع الذي تتم استعادته قديمًا بسنة أو أكثر. أعتقد أن تفريغ قاعدة البيانات كان صغيرًا بما يكفي لدرجة أنني تمكنت من تحريره في vim.

إعجاب واحد (1)

شكراً على الرد.

رفض البدء لأننا كنا متأخرين ببضع ترقيات، لذلك قمت بالتحديث إلى أحدث إصدار من Discourse عن طريق إنشاء إصدار جديد وتحميل النسخة الاحتياطية القديمة الخاصة بنا، ولكنه رفض تلك النسخة الاحتياطية بسبب المفاتيح المكررة.

أو ربما قمت بترحيل قاعدة البيانات إلى ما هو أبعد مما يمكن أن تتعامل معه الحاوية القديمة.

نعم، ربما هذا. الأمر ضبابي بعض الشيء بالضبط ما فعلته الآن، لكنني قمت بتحديث بعض الأشياء بشكل مستقل بناءً على نصائح استكشاف الأخطاء وإصلاحها هنا. كان أحد هذه الأشياء هو الحصول على أحدث إصدار من PostgreSQL.

تمكنت من تحريره في vim.

تمكنت من التحرير في Nano، وبدا كل شيء جيدًا، لكن الملف المضغوط مرة أخرى كان صغيرًا جدًا، لذا حدث خطأ ما في مكان ما.. ربما لم أتمكن من تحريره في Nano. بدا أنه نجح في ذلك الوقت.

كنت آمل أن يرى شخص ما خطأً فيه ويصححني، بحيث يصبح دليلاً إرشاديًا.

ما سأنظر إليه بعد ذلك:

  • أعد فك الضغط بالكامل. قم بضغطه دون تغيير. تحقق من أن حجم الملف المضغوط هو نفسه كما كان من قبل. إذا لم يكن كذلك، فربما لا تقوم بالضغط بنفس الخيارات؟

  • قم بفك الضغط مرة أخرى، وتحقق من حجم الملف الذي تقوم بتحريره. قم بتحريره، واحفظه، وتأكد من أن الحجم لم يتغير بشكل كبير.

إعجاب واحد (1)

تحديث بسيط. كان شخص آخر في فريقي يعمل على هذا الأسبوع الماضي ولكن لم يتم التوصل إلى حل، لذا حاولت مرة أخرى، هذه المرة عن طريق تحرير قاعدة البيانات على نظامي المحلي.

ما قمت به:

  1. قمت بتنزيل نسخة احتياطية قديمة أرغب في استعادتها
  2. قمت بفك ضغط الملفات باستخدام 7zip
  3. فتحت dump.sql باستخدام Visual Studio Code
  4. وجدت العلامات المكررة مباشرة في قاعدة البيانات.
  5. وجدت ما بدا أنه قائمة العلامات بالبحث باستخدام علامات الاقتباس المفردة حول العلامة. في حالتي ‘socialmedia’. تبدو العلامات هي الثانية والثالثة من الأسفل من المثيلات التي تم العثور عليها.

  1. قمت بتحرير واحدة لتقول

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. قمت بإعادة ضغط ملف dump.sql في 7zip
  • إضافة إلى الأرشيف
  • تنسيق الأرشيف .gzip
  1. قمت بإعادة ضغط ملف النسخ الاحتياطي الرئيسي
  • إضافة إلى الأرشيف
  • تنسيق الأرشيف .tar (gzip غير متاح بعد)
  1. يجب أن ترى الآن ملف نسخة احتياطية ثابتة .tar مضغوطة

  2. قم بضغط ملف .tar في 7zip لإنشاء ملف .tar.gz، لمطابقة التنسيق الذي يستخدمه Discourse

  • إضافة إلى الأرشيف
  • تنسيق الأرشيف .gzip
  1. قم بالتحميل إلى النسخ الاحتياطية واستعادة عبر قسم المسؤول

عند هذه النقطة واجهت رسالة خطأ:

استخراج ملف التفريغ…
[2023-08-08 15:09:15] استثناء: لا يوجد مثل هذا الملف أو الدليل @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

هل لدى أي شخص أي أفكار حول ما فاتني في العملية المذكورة أعلاه؟
الشيء الوحيد الذي يمكنني التفكير فيه هو أن المسار الذي يبحث عنه يستخدم تاريخ اليوم وليس تاريخ النسخ الاحتياطي (أكتب هذا في 2023-08-08).

هذه متابعة لمنشوري السابق هنا. أكتب مرة أخرى لتسهيل العثور عليها لأي شخص آخر يقوم بذلك في المستقبل إذا نجح الأمر.

ما قمت به لتعديل قاعدة البيانات على جهازي المحمول:

  1. قمت بتنزيل نسخة احتياطية قديمة أرغب في استعادتها من قسم المسؤول.
  2. قمت بفك ضغط الملفات باستخدام 7zip.
  3. فتحت dump.sql باستخدام Visual Studio Code.
  4. وجدت العلامات المكررة مباشرة في قاعدة البيانات.
  5. وجدت ما بدا أنه قائمة العلامات بالبحث باستخدام علامات الاقتباس حول العلامة. في حالتي ‘socialmedia’. تبدو العلامات هي الثانية والثالثة من الأسفل في المثيلات التي تم العثور عليها.

  1. قمت بتعديل واحدة لتقول:

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. قمت بإعادة ضغط ملف dump.sql في 7zip.
  • إضافة إلى الأرشيف
  • تنسيق الأرشيف .gzip
  1. قمت بإعادة ضغط ملف النسخ الاحتياطي الرئيسي.
  • إضافة إلى الأرشيف
  • تنسيق الأرشيف .tar (gzip غير متاح بعد)
  1. يجب أن ترى الآن ملف نسخة احتياطية مضغوط بصيغة .tar تم إصلاحه.

  2. قم بضغط ملف .tar في 7zip لإنشاء ملف .tar.gz، لمطابقة التنسيق الذي يستخدمه Discourse.

  • إضافة إلى الأرشيف
  • تنسيق الأرشيف .gzip
  1. قم بالتحميل إلى النسخ الاحتياطية واستعادة عبر قسم المسؤول.

عند هذه النقطة، واجهت رسالة خطأ:

استخراج ملف التفريغ…
[2023-08-08 15:09:15] استثناء: لا يوجد مثل هذا الملف أو الدليل @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

هل لدى أي شخص أي أفكار حول ما فاتني في العملية المذكورة أعلاه؟
الشيء الوحيد الذي يمكنني التفكير فيه هو أن المسار الذي يبحث عنه يستخدم تاريخ اليوم وليس تاريخ النسخ الاحتياطي (أكتب هذا في 08-08-2023).

إعجاب واحد (1)

أعتقد أن الاسم الدقيق لملف النسخ الاحتياطي مهم: اسم المنتدى، التاريخ والطابع الزمني، معرف الإصدار. لذا، إذا كنت تقوم بفك حزم وتعديل وإعادة حزم، أقترح إعادة البناء بنفس اسم الملف الأصلي. ولكن احتفظ بالملف الأصلي بأمان، بالطبع.

إعجاب واحد (1)

لقد قمت بدمج المشاركات من الموضوع الجديد في هذا الموضوع، حيث يبدو أن الاحتفاظ بهذه المشكلة مجمعة في مكان واحد سيجعل من السهل متابعتها للمسافرين في المستقبل. :+1:

إعجاب واحد (1)

شكراً @Ed_S، لقد احتفظت بالاسم الأصلي كما قرأت في مكان آخر أنه مهم. سؤالي أعلاه يتعلق بسبب أن أداة استعادة النسخ الاحتياطي كانت تبحث عن ولم تجد: /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

وهو التاريخ الذي كنت أقوم فيه بالاستعادة.

إعجاب واحد (1)

آه، عذرًا. يبدو هذا غريبًا بالفعل. قد يكون من المتوقع تمامًا أن يُطلق على الدليل المؤقت اسم وفقًا لتاريخ اليوم، ولكن لا يبدو جيدًا أن ملف تفريغ قاعدة البيانات SQL غير موجود.

إذا قمت بإدراج محتويات ملف tar، فهل ترى هذا الاسم موجودًا فيه؟ في حالتي

root@ubuntu-2gb-nbg1-1:/var/discourse/shared/standalone/backups/default# tar vtfz forumname-2023-08-03-HHMMSS-v2023mmddhhmmss.tar.gz dump.sql.gz | head
-rw-r--r-- discourse/www-data 16336925 2023-08-03 05:31 dump.sql.gz
إعجاب واحد (1)

شكراً إد، لم يكن هذا الملف موجوداً. آسف على التأخير، لقد كنت خارج الشبكة لبعض الوقت.

لا يوجد ملف بالاسم الصحيح هناك، لذا حاولت إنشاء ملف فارغ هناك يدوياً:

sudo mkdir -p /var/www/discourse/tmp/restores/default/2023-08-22-121010/

ولكن في كل مرة أضغط على استعادة، فإنه يبحث عن ملف مختلف قليلاً (آخر 6 أرقام). أفترض أنه يبحث عن مجلد تم إنشاؤه بواسطة طابع زمني، لذلك في كل مرة أضغط فيها على زر الاستعادة، يتغير المجلد الذي يبحث عنه.

أشتبه في حدوث خطأ ما في خطوتك العاشرة عند إنشاء ملف tar. هل يمكنك رؤيته؟ هل يمكنك استخدام file لوصفه؟ هل يمكنك سرد المحتويات باستخدام tar tvfz؟

إعجاب واحد (1)