نسخ النسخ الاحتياطية إلى خادم آخر باستخدام rsync و cron

ويكي المجتمع Sysadmins
1

I have a backup server that coordinates backups across many servers. I want my backup server to grab Discourse backups from my forum’s server.

I gave some thought to how I’d allow the backup server to access the backup files on the forum’s server. The best way I could come up with is allowing remote access as the www-data user (who owns Discourse’s backups).

I didn’t want to allow the backup server to shell into the forum’s server as root (for standard sysadmin reasons). I also wanted to avoid doing anything that I thought could cause Discourse to choke during backups or restores. I also wanted to avoid hosting another service on forum server.

Anyways, here’s how I did it.

Allow remote access as the www-data user

  1. Edit /etc/passwd and replace www-data’s shell with /bin/bash rather than /usr/sbin/nologin.
  2. Edit /etc/passwd again and replace www-data’s home directory with /home/www-data rather than /var/www (optional, but appealing to me).
  3. Add the backup server’s SSH key to /home/www-data/.ssh/authorized_keys.

rsync

Finally, on the backup server, I added an hourly cron command that ran the following script:

#!/usr/bin/env bash

set -xe

HOST="$1"
DIR="$2"
if [ -z "$HOST" ] || [ ! -d "$DIR" ]; then
	echo "$0 HOST DIR"
	exit 1
fi

# --ignore-existing will have rsync ignore any backups that have already been
# copied.
# --delay-updates ensures that only complete backups ever make it into $DIR. If
# this isn't specified, partial backups could end up in $DIR, and because
# --ignore-existing won't perform any kind of equality check, the problem will
# not be corrected or detected.
rsync --ignore-existing --delay-updates "$HOST:/var/discourse/shared/standalone/backups/default/*" "$DIR"

Hopefully this proves useful to someone out there.

8 إعجابات
2

رائع!!
على الرغم من أنني سأقدر ذلك كثيرًا إذا شرحت الخطوات المذكورة أدناه بتفصيل أكبر حتى لا يرتكب المستخدمون المبتدئون مثلي أي خطأ (ويحصلون أيضًا على فكرة عما يفعله كل خطوة).

ماذا يفعل ما سبق؟

هل تقصد المفتاح العام هنا؟

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

يسمح للمستخدم www-data بتسجيل الدخول بنجاح. هذا يغير “shell تسجيل الدخول” وهو مصطلح رئيسي جيد للبحث عنه لمعرفة المزيد.

نعم. يجب (بشكل أساسي) عدم نسخ المفاتيح الخاصة/مشاركتها في أي مكان خارج جهازها المضيف.

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

نظرًا لأنك شخص جديد في البحث، هل هناك طريقة بسيطة لنقل نسخة احتياطية من خادمنا المحلي إلى S3 buckets مختلفة، مثل Google S3، iDrive S3 عبر cron jobs؟
(أعلم أنه يمكننا تكوينه لـ AWS S3 bucket مباشرة باستخدام مفتاحه وسره).

5

إذا قمت بتكوين النسخ الاحتياطي لـ S3، فسيتم تحميلها إلى S3 تلقائيًا، على الرغم من أنها تحتوي إما على جميع التحميلات أو لا شيء منها، لذلك ما لم يكن لديك تحميلات على S3، سيكون لديك نسخ متعددة من جميع التحميلات في ملفات النسخ الاحتياطي.

إعجابَين (2)
6

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

لكنني كنت أسأل عما سبق لمشكلة مختلفة أواجهها.
الآن، قمت بإعداد لإنشاء نسخ احتياطية (تتضمن الوسائط ‘التحميلات’) على خادم Ubuntu محلي. ولكن (كما تمت مناقشته في موضوع آخر)، لا يمكنني الاستعادة من تلك النسخ الاحتياطية (بحجم 1 جيجابايت). هناك شيء مفقود/يسبب مشكلة. لذلك كنت أفكر في استخدام حاوية Google والتخلي عن AWS تمامًا.

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

لا أرى الفرق بين AWS S3 و Google. ولكن ربما سيساعدك https://restic.net/؟ إنه برنامج نسخ احتياطي يمكنه النسخ الاحتياطي إلى حاويات s3.

لست متأكدًا من مشكلة الاستعادة لديك.

إعجابَين (2)
8

لكل من يأتي إلى هذا الموضوع مثلي، أود أن أشرح هذا المنشور الأول في الموضوع بشكل أكبر.

  • هذا نص برمجي bash، يمكن لصقه “كما هو” في ملف باسم أي شيء، ولكن له امتداد .sh
  • السطر الأول من النص البرمجي يضبط البيئة لتشغيل النص البرمجي، فيما يتعلق بأي shell أو بيئة يجب استخدامها: #!/usr/bin/env bash: يخبر هذا النظام باستخدام مترجم bash الذي تم العثور عليه عبر أمر env.
  • الأعلام (set -xe):
  • -x: يُمكّن التصحيح، مما يعني أن كل أمر وحججه سيتم طباعتها في الطرفية قبل تنفيذها. هذا مفيد لتصحيح النص البرمجي.
  • -e: يتسبب في إنهاء النص البرمجي فورًا إذا أعاد أي أمر حالة غير صفرية (تشير إلى خطأ). هذا مفيد لمنع النص البرمجي من الاستمرار بعد فشل.
  • وفي الخطوة المهمة التالية، المتغيرات (HOST="$1" DIR="$2"):
  • HOST="$1": يعين الوسيط الأول الذي تم تمريره إلى النص البرمجي ($1) إلى المتغير HOST. أي أنه عند تشغيل هذا النص البرمجي، سيطلب بعض المدخلات من المستخدم، وأي مدخل أول ($1) سيدخله المستخدم، سيتم تمريره/اعتباره كقيمة “المضيف” (من حيث سيتم نسخ البيانات ربما).
  • DIR="$2": يعين الوسيط الثاني الذي تم تمريره إلى النص البرمجي ($2) إلى المتغير DIR. أي أن أي شيء (مسار دليل) سيدخله المستخدم بعد إدخال القيمة الأولى (المسمى $2) سيأخذه النص البرمجي كـ “دليل الهدف”.
    إذا كان أي شخص مهتمًا، يمكنني شرح الخطوتين المتبقيتين أيضًا، ولكن يكفي القول إن الخطوة التالية تتحقق فقط من أن المستخدم يوفر قيم المضيف والدليل الهدف الصحيحة عند المطالبة. وإلا (الخطوة الأخيرة) ستعيد 1 كمخرج خطأ.
    الشيء الرئيسي الذي أكرره هو أن هذا نص برمجي، عند تشغيله، سيطلب من المستخدم المضيف (من أين سيتم نسخ البيانات) والدليل الهدف (حيث سيتم لصق البيانات). وستقوم بتضمين المسار إلى هذا الملف في ملف cron job الخاص بك، والذي قد يقوم بتشغيل ملف النص البرمجي هذا عدة مرات في اليوم كما تحدده في ملف cron.

ولكن ما فشلت في فهمه هو أين تتم عمليات النسخ واللصق الفعلية (أو النسخ الاحتياطي)؟
كيف سيحدث المزامنة الفعلية؟

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