كيف تنسخ حاوية Docker لـSQLite احتياطيًا (2026)
أتريد نسخة SQLite تُستعاد فعلًا؟ فرّغها بالأمر `sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"` من داخل الحاوية بدل نسخ /data/app.db. تقرأ واجهة النسخ الاحتياطي المتصلة في SQLite (sqlite3 ".backup" أو VACUUM INTO) نسخة متسقة تحترم WAL والمعاملات الجارية — ما لا يستطيعه نسخ الملف الخام. ثم يسلّم Dockstash التفريغ إلى restic للقطات مشفّرة ومزالة التكرار وخارجية.
ما يكتشفه Dockstash
| متغيرات البيئة المكتشفة | DATABASE_PATH, DATABASE_URL, DB_PATH |
|---|---|
| المنفذ الافتراضي | — |
| مسارات البيانات الحية (لا تُنسخ حية أبدًا) | /data/app.db, /data/app.db-wal, /data/app.db-shm |
| أمثلة الصور | embedded (no dedicated image), alpine + sqlite, app images bundling sqlite |
انسخ SQLite مع Dockstash خطوة بخطوة
أنشئ حساب Dockstash وافتح لوحة التحكم
سجّل مجانًا على app.dockstash.com/register. يسألك معالج الإعداد لمرة واحدة عن خادم التخزين VPS (الجهاز الذي سيحتفظ بالنسخ الاحتياطية المشفّرة) ويولّد كلمة مرور تشفير — احفظها فورًا في مدير كلمات مرور، فهي تُعرض مرة واحدة فقط.
أضف مشروع Docker المضمّن فيه SQLite
في شاشة Projects يكتشف Dockstash تلقائيًا كل مجلد مشروع Compose (افتراضيًا تحت /var/www). اختر المشروع الذي يخزّن تطبيقه بياناته في ملف SQLite — تفعل ذلك PocketBase وVaultwarden وUptime Kuma وGitea وGhost جميعًا. لم يُنسخ شيء بعد.
تحقق من اكتشاف SQLite
افتح المشروع وتبويب Plan. لا حاوية مستقلة لـSQLite — يعيش داخل صورة تطبيقك — لذا يعثر عليه Dockstash عبر متغيرات البيئة المشيرة إلى ملف القاعدة (DATABASE_PATH وDATABASE_URL وDB_PATH) ويضيف طبقة تلتقطه عبر واجهة النسخ الاحتياطي المتصلة. فعّل أو عطّل الملفات والقواعد وإعدادات الوكيل قبل الحفظ.
اختياري: تحقق من النسخة يدويًا
إن أردت دليلًا قبل الأتمتة، نفّذ الأمر نفسه: sqlite3 /data/app.db ".backup '/tmp/app-backup.db'" داخل حاوية التطبيق. لا يطبع شيئًا عند النجاح ويترك نسخة كاملة متسقة في /tmp/app-backup.db — بمحتوى WAL. هذه النسخة هي ما يُنسخ، وليس ملف .db الحي أبدًا.
docker exec <app-container> sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"أكّد وجهة التخزين
تُخزَّن النسخ كلقطات restic مشفّرة على خادم التخزين VPS الخاص بك عبر SSH. إن أكملت معالج الإعداد فهي مهيّأة بالفعل؛ ويمكنك تغيير المضيف والمستخدم والمنفذ ومفتاح SSH في أي وقت من Settings → Storage.
اضبط جدول النسخ الاحتياطي
في تبويب Schedule اختر يوميًا أو أسبوعيًا أو cron مخصصًا (يُتحقق أثناء الكتابة). يوميًا في ساعة هادئة هو الافتراضي الصحيح لمعظم تطبيقات SQLite. أضف prune أسبوعيًا مع سياسة الاحتفاظ.
شغّل أول نسخة احتياطية الآن
انقر Backup Now. ينفّذ Dockstash أمر .backup داخل حاوية التطبيق لإنتاج نسخة متسقة من القاعدة ثم يدفقها — مع ملفات المشروع — إلى restic. تابع المخرجات الحية في لوحة السجلات.
تأكد من وجود اللقطة
عند انتهاء التشغيل تعرض بطاقة المشروع وقت آخر نسخة وعدد اللقطات وحجم المستودع. افتح شاشة Snapshots وسترى نقطة الاستعادة في الخط الزمني — هذا دليلك على وصول النسخة إلى موقعها الخارجي.
أمر التفريغ
sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"أمر الاستعادة
copy the .backup file into place while the app is stopped, or use .restoreتقرأ واجهة النسخ الاحتياطي المتصلة في SQLite (sqlite3 ".backup" أو VACUUM INTO) نسخة متسقة تحترم WAL والمعاملات الجارية — ما لا يستطيعه نسخ الملف الخام.
استعد نسخة SQLite وأثبت أنها تعمل
نسخة SQLite الاحتياطية لا تصبح حقيقية إلا بعد استعادتها. استعادات Dockstash لا تكتب فوق قاعدتك الحية افتراضيًا — إلى موقع جديد أولًا، فحص، ثم ترقية واعية.
اختر نقطة استعادة
افتح Snapshots واختر المشروع وتصفح الخط الزمني. كل صف يحوي نسخة أحادية الملف متسقة من القاعدة — منتَجة عبر واجهة النسخ المتصلة، فلا ملفات جانبية -wal أو -shm للمطابقة — مع ملفات المشروع من التشغيل نفسه.
استعد إلى موقع جديد
انقر Restore وأبقِ الوضع الافتراضي «Restore to new location». اكتب اسم المشروع للتأكيد — إجراء متعمّد بتأكيد مكتوب. يهبط التفريغ والملفات في المسار الهدف الذي تختاره دون المساس بالمشروع الحي.
تحقق من البيانات المستعادة
نفّذ sqlite3 <الملف-المستعاد> "PRAGMA integrity_check;" — قاعدة سليمة تجيب بـ«ok» واحدة. ثم افتح الملف بـsqlite3 وافحص عينات من جداول تطبيقك: عدّ الصفوف والسجلات الحديثة أسرع اختبار.
docker exec <app-container> sqlite3 /tmp/app-backup.db "PRAGMA integrity_check;"رقِّ النتيجة عند الاقتناع
بعد التحقق: أوقف التطبيق واستبدل ملف قاعدته بالنسخة المستعادة ثم أعد تشغيله (أو أعد الاستعادة بوضع «Overwrite existing» — موافقة صريحة). الأفضل: دع التدريب الأسبوعي ينتج هذا الدليل تلقائيًا.
مطبات يجب تجنبها
- لا تنسخ ملف .db حيًا والتطبيق يعمل بوضع WAL — ستفوّت الملفات الجانبية -wal/-shm وتلتقط قاعدة ممزقة غير قابلة للاستعادة.
- استخدم sqlite3 ".backup" أو «VACUUM INTO» — كلاهما يمر بواجهة النسخ المتصلة ويتعامل مع WAL صحيحًا.
- checkpoint (PRAGMA wal_checkpoint(TRUNCATE)) قبل نسخ خام لا يعوّض واجهة النسخ مع كتابة متزامنة.
مشكلات شائعة في نسخ SQLite
- العرض
- القاعدة المستعادة تفتح لكن أحدث الصفوف مفقودة.
- السبب
- كانت النسخة نسخًا خامًا لملف .db وحده والتطبيق يعمل بوضع WAL — أحدث الكتابات كانت في الملف الجانبي -wal ولم تصل النسخة قط.
- العلاج
- لا تنسخ قاعدة WAL حية نسخًا خامًا أبدًا. استخدم sqlite3 ".backup" أو VACUUM INTO — يمران عبر واجهة النسخ المتصلة ويطويان WAL داخل النسخة. لهذا بالضبط يستخدم Dockstash هذه الواجهة.
- العرض
- يفشل أمر .backup برسالة «database is locked».
- السبب
- معاملة كتابة طويلة (أو كاتب معلّق) تمسك قفل القاعدة وsqlite3 استسلم قبل تحريره.
- العلاج
- اضبط مهلة انشغال (sqlite3 -cmd ".timeout 30000" أو PRAGMA busy_timeout) لينتظر النسخ بدل الفشل، وجدوِل النسخ في ساعة هادئة. إن لم يتحرر القفل فابحث عن عملية كاتب معلّقة في الحاوية.
- العرض
- PRAGMA integrity_check على ملف منسوخ يجيب «database disk image is malformed».
- السبب
- نُسخ الملف والتطبيق يكتب فيه — التقاط صفحة ممزقة لا تصلحه أي أداة بثقة.
- العلاج
- ارمِ النسخة الممزقة واستعد من لقطة أنتجتها واجهة النسخ. كل لقطة من Dockstash تُلتقط بـ".backup": يجب أن يجيب integrity_check بـ«ok» — وهذا ما تفحصه خطوة التحقق.
- العرض
- نفّذت PRAGMA wal_checkpoint(TRUNCATE) قبل نسخ خام والنسخة ما تزال غير متسقة.
- السبب
- يطوي checkpoint صفحات WAL في الملف الرئيسي عند لحظة، لكن الكتّاب قد يضيفون إطارات WAL جديدة فور انتهائه — «checkpoint ثم cp» ليس لقطة ذرّية مع كتابة متزامنة.
- العلاج
- عُدَّ «checkpoint ثم نسخ» مغالطة لا تقنية. اللقطة الحية الآمنة الوحيدة هي واجهة النسخ المتصلة (".backup" أو VACUUM INTO)؛ النسخ الخام آمن فقط والتطبيق موقوف.
أنجزه بنقرة واحدة مع Dockstash
ينفّذ Dockstash التفريغ أعلاه بالضبط ويسلّمه إلى restic خارجيًا ويختبر الاستعادة بتدريب تلقائيًا — بلا سكربت تصونه.
آخر تحديث: July 2026
الأسئلة الشائعة
ألا يمكنني نسخ ملف .db فحسب؟
ليس بأمان والتطبيق يكتب. في وضع WAL تعيش أحدث البيانات في الملف الجانبي -wal؛ نسخ .db وحده يلتقط حالة قديمة ممزقة. استخدم sqlite3 ".backup" أو «VACUUM INTO» اللذين يقرآن نسخة متسقة عبر الواجهة المتصلة.
ما هو VACUUM INTO؟
يكتب VACUUM INTO 'file.db' نسخة جديدة مُرتَّبة ومتسقة معاملاتيًا من القاعدة في ملف جديد. طريقة نظيفة للقطة قاعدة SQLite حية دون إيقاف التطبيق.
هل أحتاج نسخ ملفي -wal و-shm؟
مع واجهة النسخ لا — فهي تدمج WAL في النسخة. إن أصررت على نسخ خام (غير منصوح به حيًا) فيلزم تضمين -wal و-shm ويبقى معرضًا للسباقات.
كيف أستعيد نسخة SQLite؟
أوقف التطبيق واستبدل ملف القاعدة بناتج .backup ثم شغّل التطبيق. النسخة ملف واحد متسق: لا ملفات جانبية للمطابقة.
تطبيقي يضمّن SQLite (مثل PocketBase وVaultwarden وUptime Kuma) — هل يجده Dockstash؟
نعم. لا حاوية SQLite منفصلة تُكتشف: يقرأ Dockstash إعداد compose ومتغيرات التطبيق (DATABASE_PATH وDATABASE_URL وDB_PATH) لتحديد الملف ثم يلتقطه بواجهة النسخ. راجع المسار المكتشف في تبويب Plan قبل أول تشغيل.
كم مرة يجب نسخ SQLite؟
يوميًا هو الافتراضي العملي للتطبيقات أحادية الملف؛ وكل ساعة إن كان فقدان يوم غير مقبول. في Free النسخ يدوي (Backup Now)؛ Pro حتى الساعي وBusiness أي cron.
أين تعيش النسخ الاحتياطية فعليًا؟
على خادم التخزين VPS الخاص بك، كلقطات restic مشفّرة تُدفع عبر SSH. لا يحتفظ Dockstash ببياناتك أبدًا على سحابة طرف ثالث — أنت توجّهه إلى جهاز تتحكم فيه، والمستودع مشفّر بكلمة مرور لا يملكها سواك.
كيف أعرف أن النسخة قابلة للاستعادة دون استعادة يدوية؟
جدوِل تدريب استعادة. يستعيد Dockstash أحدث لقطة إلى مساحة عمل معزولة، ويقارن كل ملف بايتًا ببايت مع المصدر، ويتحقق من التفريغ المستعاد — ثم يختم المشروع بشارة نجاح/فشل. تدريب أسبوعي يعني دليلًا طازجًا دائمًا.