محتوای آموزشی وبلاگ نت‌آرام
بکاپ لینوکس تقریباً تمام شده، اما در پایان می‌بینید:
file changed as we read it. معنی جمله ساده است: tar مشغول خواندن یک فایل بوده و همان فایل در این فاصله تغییر کرده است. آرشیو ممکن است ساخته شده باشد، اما وجود فایل بکاپ به‌تنهایی ثابت نمی‌کند محتوای آن یک نسخه دقیق و قابل بازیابی از داده‌هاست.این اتفاق برای فایل گزارش، کش، فایل آپلودی یا حتی داده پایگاه داده رخ می‌دهد. اهمیت آن‌ها یکسان نیست. حذف هشدار از صفحه، مشکل سازگاری داده را برطرف نمی‌کند. ابتدا فایل را شناسایی می‌کنیم، بعد بر اساس نوع داده روش مناسب بکاپ می‌گیریم و در پایان بازیابی آزمایشی انجام می‌دهیم.
در مثال‌ها فرض می‌کنیم داده سایت در
/var/www/site است و دیسک پشتیبان در /mnt/backup نصب شده است. این مسیرها نمونه‌اند؛ مسیرهای واقعی خود را جایگزین کنید. به SSH، مجوز sudo و فضای کافی در مقصد نیاز دارید. پیش از توقف سرویس یا ساخت snapshot، زمان نگهداری و اثر آن بر کاربران را مشخص کنید.۱. نام فایل و وضعیت دستور را یادداشت کنید
وقتی tar هشدار می‌دهد، نام فایل معمولاً پیش از پیام آمده است. مشخص کنید فایل متعلق به کدام برنامه است و آیا جزء اطلاعاتی است که باید در بازیابی برگردد. اگر لاگ را ندارید، دفعه بعد خروجی را در یک محیط امن مشاهده کنید؛ مسیرها ممکن است نام مشتری یا اطلاعات داخلی داشته باشند.
در GNU tar، خروجی موفق معمولاً کد صفر دارد. هنگام ساخت آرشیو، کد ۱ می‌تواند به تغییر فایل حین خواندن اشاره کند و کد ۲ خطای جدی را نشان می‌دهد. فشرده‌ساز یا برنامه فرعی نیز ممکن است کد دیگری برگرداند. کد را بلافاصله پس از دستور ببینید:
کد / دستورecho $?
اگر پیش از این دستور کار دیگری اجرا کرده باشید، عدد مربوط به همان دستور جدید است، نه tar. بنابراین در بکاپ بعدی کد را بلافاصله در یک متغیر ذخیره می‌کنیم. حتی کد صفر هم ثابت نمی‌کند یک برنامه در حال تغییر، از نظر تمام فایل‌ها و دیتابیس تصویر سازگار داشته است.
۲. مقصد را از مبدأ جدا کنید
اول بررسی کنید دیسک مورد انتظار واقعاً متصل است:
کد / دستورmountpoint /mnt/backup
اگر پیام می‌گوید این مسیر mountpoint نیست و قرار بوده دیسک مستقلی باشد، ادامه ندهید؛ نوشتن بکاپ در پوشه خالی ممکن است دیسک اصلی را پر کند. مسیر و فایل‌سیستم را نیز ببینید:
کد / دستورfindmnt -T /mnt/backup
کد / دستورdf -h /mnt/backup
خروجی
findmnt مشخص می‌کند مسیر اکنون روی کدام فایل‌سیستم است و df فضای آزاد آن را نشان می‌دهد. آرشیو را داخل پوشه‌ای که خود tar در حال خواندن آن است قرار ندهید. اگر مقصد بکاپ را روی همان فایل‌سیستم نیاز دارید، بدانید پر شدن یا خرابی همان دیسک می‌تواند نسخه اصلی و بکاپ را با هم از بین ببرد.برای مثال یک پوشه اختصاصی و تازه با دسترسی محدود بسازید:
کد / دستورsudo mkdir -m 0700 /mnt/backup/site-backups
اگر پوشه از قبل وجود دارد، دستور خطا می‌دهد؛ به‌جای تغییر دسترسی یک پوشه ناشناس، مسیر و مالک آن را بررسی کنید. دستور زیر فقط مجوز و مالک را نشان می‌دهد:
کد / دستورsudo stat -c '%a %U %G %n' /mnt/backup/site-backups
بکاپ ممکن است رمزهای برنامه و اطلاعات کاربران را شامل شود؛ مسیر ذخیره باید تنها در اختیار افراد مجاز باشد.
۳. چرا این فایل تغییر می‌کند؟
روی یک فایل نمونه که در هشدار آمده، اندازه و زمان تغییر را ببینید:
کد / دستورsudo stat -c '%n size=%s modified=%y' /var/www/site/example.log
چند لحظه بعد همان دستور را تکرار کنید. اگر اندازه یا زمان عوض می‌شود، برنامه‌ای احتمالاً در حال نوشتن است. اگر
کد / دستورlsof نصب است، می‌توانید فرایندهای دارای فایل باز را ببینید:sudo lsof /var/www/site/example.log
نام واقعی فایل را جایگزین کنید. خروجی می‌تواند نام فرایند و PID را نشان دهد، اما خالی بودنش ثابت نمی‌کند فایل هیچ‌وقت تغییر نمی‌کند. سپس بر اساس نوع فایل تصمیم بگیرید:
- کش قابل بازسازی: اگر مستند برنامه تأیید می‌کند حذف کش به اطلاعات اصلی آسیب نمی‌زند، می‌توان همان پوشه کش را از بکاپ کنار گذاشت.
- لاگ: مشخص کنید برای تحلیل و الزامات نگهداری به آن نیاز دارید یا نه. اگر لازم است، به جای حذف، برنامه چرخش لاگ یا روش بکاپ سازگار آن را تنظیم کنید.
- آپلود کاربر یا فایل برنامه: آن را نادیده نگیرید. باید نوشتن را برای مدت بکاپ متوقف کنید یا از یک نسخه پایدار مناسب استفاده کنید.
- فایل خام دیتابیس فعال: تنها با tar گرفتن از پوشه در حال کار پایگاه داده، نسخه سازگار تضمین نمی‌شود. از ابزار بکاپ همان پایگاه داده استفاده کنید.
۴. روش اول: بکاپ از فایل‌هایی که نوشتن روی آن‌ها متوقف شده است
در زمان نگهداری، ورودی‌های برنامه، کارهای زمان‌بندی‌شده و workerهایی را که به این پوشه می‌نویسند با روش همان نرم‌افزار متوقف کنید. صرف بستن صفحه مرورگر یا فعال کردن یک صفحه نگهداری همیشه تمام نوشتن‌ها را متوقف نمی‌کند. فقط سرویس‌های مربوط را با شناخت کامل متوقف کنید؛ خاموش کردن وب‌سرور مشترک ممکن است سایت‌های دیگر را هم قطع کند.
وقتی مطمئن شدید مجموعه فایل‌های موردنیاز پایدار است، یک نام تازه برای آرشیو بسازید:
کد / دستورarchive=$(sudo mktemp /mnt/backup/site-backups/site-XXXXXXXX.tar.gz)
اگر دستور خطا داد یا متغیر خالی بود، ادامه ندهید.
کد / دستورmktemp فایل جدیدی با نام متفاوت و مجوز محدود می‌سازد؛ این کار از رونویسی تصادفی بکاپ قبلی جلوگیری می‌کند. مسیر را برای مراحل بعدی در همان نشست نگه دارید:printf '%s\n' "$archive"
حالا فایل‌های سایت را کپی کنید:
کد / دستورsudo tar -czf "$archive" -C /var/www/site .
tar_status=$?
printf 'tar exit status: %s\n' "$tar_status"
-C ابتدا وارد پوشه مبدأ می‌شود و . محتوای آن را با مسیر نسبی در آرشیو می‌گذارد؛ -c آرشیو می‌سازد، -z فشرده‌سازی gzip را فعال می‌کند و -f نام مقصد را مشخص می‌کند. اگر کد غیرصفر است یا پیام خطا می‌بینید، آرشیو را بکاپ نهایی موفق در نظر نگیرید؛ علت دقیق را رفع و با نام تازه دوباره امتحان کنید. پس از اتمام، سرویس‌های متوقف‌شده را طبق برنامه به وضعیت اولیه برگردانید و عملکرد سایت را بررسی کنید.اگر فقط یک پوشه کش مشخص واقعاً قابل بازسازی است، نمونه زیر آن را کنار می‌گذارد:
کد / دستورsudo tar --exclude='./cache' -czf "$archive" -C /var/www/site .
این یک نمونه مستقل است؛ برای جلوگیری از رونویسی، پیش از آزمایش آن متغیر
archive را با یک mktemp تازه بسازید. نام کش باید با مسیر واقعی آرشیوشده تطبیق داشته باشد. پوشه آپلود، تنظیمات یا داده کاربر را صرفاً برای حذف هشدار کنار نگذارید.۵. روش دوم: خروجی سازگار از پایگاه داده
اگر برنامه از MySQL با جدول‌های InnoDB استفاده می‌کند، یک روش رایج، خروجی منطقی با
mysqldump است. نسخه، مجوزهای حساب بکاپ و نیازهای برنامه شما اهمیت دارند. دستور زیر یک نمونه است، نه نسخه مناسب همه پایگاه‌های داده. در همان زمان بکاپ، تغییر ساختار جدول‌ها مانند ALTER یا DROP انجام ندهید.ابتدا فضای پوشه خانگی و یک نام تازه را بررسی کنید:
کد / دستورdf -h "$HOME"
dbfile=$(mktemp "$HOME/site-db-XXXXXXXX.sql")
نام پایگاه داده و حساب مجاز را جایگزین کنید:
کد / دستورmysqldump -u backupuser -p --single-transaction --quick --databases exampledb > "$dbfile"
dump_status=$?
printf 'dump exit status: %s\n' "$dump_status"
گزینه
-p رمز را در اعلان جدا می‌خواهد؛ رمز را بعد از آن در خط فرمان ننویسید. --single-transaction برای جدول‌های تراکنشی مانند InnoDB یک خواندن سازگار فراهم می‌کند، اما جدول‌های غیرتراکنشی مثل MyISAM را در برابر تغییر هم‌زمان تضمین نمی‌کند. همچنین هماهنگی زمانی میان دیتابیس و فایل‌های سایت همچنان مسئولیت شماست. اگر کد صفر نیست، خروجی ممکن است ناقص باشد؛ آن را نسخه موفق ندانید.فایل SQL حساس است. آن را با مجوز محدود نگه دارید، همراه سایر اجزای بکاپ با روش امن انتقال دهید و در سرور اصلی به اشتباه روی دیتابیس فعال بازگردانی نکنید. روال‌ها، eventها و جزئیات حساب بکاپ به نیاز سامانه و نسخه دیتابیس بستگی دارند؛ برای بازیابی واقعی آن‌ها را در برنامه بکاپ پوشش دهید.
۶. اگر قطع نوشتن ممکن نیست
از قابلیت snapshot فایل‌سیستم یا سرویس بکاپ سازگار با برنامه خود استفاده کنید. Snapshot دیسک معمولاً تصویری از لحظه مشخص می‌دهد، اما سازگاری خود برنامه و دیتابیس به روش snapshot و آماده‌سازی برنامه بستگی دارد. به‌خصوص سرور دیتابیس را صرفاً با این فرض که دیسک snapshot دارد سالم فرض نکنید. پیش از اجرا، فضای لازم، مدت نگهداری snapshot و روش بازگردانی را با مستند ارائه‌دهنده بررسی کنید؛ پر شدن فضای snapshot هم می‌تواند بکاپ را بی‌اعتبار کند.
برای کم کردن بار خواندن، می‌توان ابتدا داده‌های فایل را به محلی جدا همگام کرد، سپس در بازه نگهداری تغییرات آخر را منتقل و از نسخه ثابت آرشیو ساخت. تا وقتی نوشتن به فایل‌های نسخه کپی‌شده متوقف نشده، rsync دوم یا tar هم به‌تنهایی یک snapshot تضمین‌شده ایجاد نمی‌کند.
۷. سلامت آرشیو و بازیابی را امتحان کنید
پس از بکاپ موفق، در همان نشست که
کد / دستورarchive مقدار دارد، فهرست را بررسی کنید:sudo tar -tzf "$archive" >/dev/null
خروجی خالی و کد صفر یعنی خواندن فهرست آرشیو بدون خطای گزارش‌شده انجام شده است. آزمایش فشرده‌سازی:
کد / دستورsudo gzip -t "$archive"
این آزمون خرابی جریان gzip را بررسی می‌کند، اما ثابت نمی‌کند فایل‌ها هنگام بکاپ از نظر برنامه سازگار بوده‌اند. برای آزمون بازگردانی، یک پوشه کاملاً تازه بسازید:
کد / دستورsudo mkdir -m 0700 /var/tmp/site-restore-check
اگر پوشه وجود دارد، نام تازه‌ای انتخاب کنید. فقط آرشیوی را باز کنید که خودتان ساخته‌اید و به آن اعتماد دارید:
کد / دستورsudo tar --no-same-owner --no-same-permissions -xzf "$archive" -C /var/tmp/site-restore-check
این استخراج آزمایشی مالک و مجوز اصلی را بازسازی نمی‌کند؛ هدف، بررسی محتوا در مسیر جداست. چند فایل مهم را باز کنید و در محیط آزمایشی برنامه، دیتابیس و فایل‌ها را با هم بازیابی و عملکرد را امتحان کنید. برای بازیابی واقعی ممکن است لازم باشد مالکیت، ACL و مجوزها را با روش مستند سامانه برگردانید.
اگر دیسک مقصد ظاهراً نصب بوده ولی فایل روی ریشه ذخیره شده، راهنمای مشکل mount مقصد بکاپ را ببینید. این مراقبت‌ها هم برای سرور مجازی ایران و هم سرور اختصاصی ایران لازم‌اند. جزئیات کدهای خروج در راهنمای GNU tar و محدودیت تراکنش در مستند mysqldump مای‌اس‌کیوال توضیح داده شده است.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام