المستوى: متوسط. الشرح ده مبني على فرضية إن قاعدة بياناتك أقل من 50 جيجابايت وتقدر تتحمّل نسخة منطقية (logical dump) يومية. لو أكبر من كده بكتير أو محتاج استرجاع في ثواني، فيه قسم في الآخر بيقولك تعمل إيه.
أتمتة نسخ PostgreSQL الاحتياطية على S3 بـ restic
في آخر المقال هيبقى عندك سكربت واحد بيرفع نسخة مشفّرة ومضغوطة من قاعدة بياناتك على S3 كل ليلة، يمسح القديم لوحده، ويتأكد إن النسخة سليمة فعلًا. صفر تدخل يدوي.
المشكلة باختصار
معظم الفرق بتكتب سطر pg_dump في cron وتنساه. الطريقة دي بتفشل في اللحظة اللي محتاجها فعلًا. النسخة بتتخزّن على نفس الديسك بتاع القاعدة، من غير تشفير، وبتكبر لحد ما تملأ القرص، ومحدش بيجرّب يرجّعها.
سيناريو واقعي: عندك قاعدة app_production حجمها 18 جيجا على سيرفر واحد. حصل تلف في الديسك أو اتمسح الـ volume بالغلط. نسختك الاحتياطية كانت جنبها على نفس السيرفر، فراحت مع الأصل. ده بالظبط اللي قاعدة الـ 3-2-1 بتحذّر منه: 3 نسخ، على وسيطين مختلفين، واحدة منهم خارج الموقع (offsite).
ليه pg_dump لوحده مش كفاية
- نسخة واحدة على نفس القرص: أي عطل في الهاردوير بياخد الأصل والنسخة سوا.
- بدون تشفير: أي حد يوصل للملف يقرأ بيانات عملائك بالكامل.
- بتكبر بلا حدود: كل يوم dump كامل جديد، فالمساحة بتنفجر خلال أسابيع.
- مش متجرَّبة: نسخة معملتش لها restore مرة واحدة هي مجرد وهم أمان.
restic في جملة واحدة
تخيّل إنك بتصوّر كتاب 500 صفحة كل يوم عشان تحتفظ بنسخة. لو كل يوم بتصوّر الكتاب كله، ده هدر رهيب. الأذكى إنك تصوّر الصفحات اللي اتغيّرت بس، وتشاور على الباقي إنه زي إمبارح. ده بالظبط اللي restic بيعمله.
بالتفاصيل العلمية: restic بيقسّم البيانات لقطع متغيّرة الحجم بأسلوب content-defined chunking، وبيبصم كل قطعة ببصمة تشفيرية. القطعة اللي اتخزّنت قبل كده مبتتخزّنش تاني (deduplication)، وكل حاجة بتتشفّر بـ AES-256 قبل ما تسيب سيرفرك. النتيجة: مستودع (repository) على S3 فيه كل تاريخ نسخك، بحجم أقل بكتير من مجموع النسخ الكاملة.
السكربت الكامل (قابل للنسخ)
أول مرة بس، جهّز المستودع على S3:
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="********"
export RESTIC_REPOSITORY="s3:s3.eu-central-1.amazonaws.com/mycompany-db-backups"
export RESTIC_PASSWORD_FILE="/etc/restic/password.txt"
restic init