محتوای آموزشی وبلاگ نت‌آرام
فایل‌های سایت را با rsync به سرور تازه منتقل کرده‌اید. حجم فایل‌ها درست است، اما سایت خطای دسترسی می‌دهد یا مالک پوشه‌ها به نام دیگری نمایش داده می‌شود. مشکل ممکن است از تفاوت شناسه‌های عددی کاربران، نام‌های متفاوت در دو سرور یا نداشتن مجوز برای تغییر مالک در مقصد باشد.
لینوکس در پشت نام‌هایی مانند
alice، عددی به نام UID برای کاربر و GID برای گروه نگه می‌دارد. دو سرور می‌توانند حسابی همنام با عددهای متفاوت داشته باشند؛ همچنین یک عدد ممکن است در دو سرور متعلق به دو حساب متفاوت باشد. بنابراین دیدن نام فایل کافی نیست و باید هر دو طرف را مقایسه کنیم.این مقاله برای انتقال فایل بین دو سرور لینوکسی است. برای دستورهای نمونه به دسترسی مجاز، SSH و نصب rsync در هر دو طرف نیاز دارید. مسیرها و حساب‌های نمونه را با اطلاعات واقعی جایگزین کنید. قبل از انتقال اصلی از فایل‌ها و تنظیمات نسخه پشتیبان قابل بازیابی داشته باشید. کپی فایل‌های یک پایگاه داده در حال نوشتن لزوماً بکاپ سالم آن نیست؛ برای دیتابیس از روش پشتیبان‌گیری سازگار با همان پایگاه داده استفاده کنید.
۱. نام و عدد مالک را در سرور مبدأ پیدا کنید
وارد سرور قدیمی شوید. مسیر نمونه را با یک فایل واقعی و غیرحساس از برنامه خود جایگزین کنید:
کد / دستورls -l /srv/project-data/example.txt
ستون‌های مالک و گروه معمولاً به شکل نام نمایش داده می‌شوند. حالا همان فایل را با شناسه عددی ببینید:
کد / دستورls -ln /srv/project-data/example.txt
برای نمایش واضح‌تر هر دو مقدار:
کد / دستورstat -c '%n owner=%U(%u) group=%G(%g)' /srv/project-data/example.txt
فرض کنید نتیجه نام
کد / دستورalice و UID برابر ۱۰۰۰ است. این‌ها فقط عددهای نمونه‌اند. اگر برای نام کاربر علامت سؤال یا عدد می‌بینید، ممکن است نام متناظر روی آن سیستم موجود نباشد. حساب و گروه مربوط را نیز با نام واقعی بررسی کنید:getent passwd alice
کد / دستورid alice
خروجی
id، UID، گروه اصلی و گروه‌های دیگر آن حساب را نشان می‌دهد. از چند فایل متعلق به کاربران مختلف نمونه بگیرید؛ همه فایل‌های یک سایت الزاماً مالک یکسان ندارند.۲. همان هویت را در مقصد مقایسه کنید
وارد سرور جدید شوید و دستورهای زیر را اجرا کنید:
کد / دستورgetent passwd alice
کد / دستورgetent group alice
ممکن است
کد / دستورalice در مبدأ UID برابر ۱۰۰۰ و در مقصد UID برابر ۲۰۰۰ داشته باشد. اگر هر دو واقعاً حساب همان شخص یا برنامه هستند، یکی کردن نام نمایشی با نگه داشتن عدد، نتیجه‌های متفاوتی ایجاد می‌کند. همچنین بررسی کنید UID مبدأ در مقصد متعلق به چه کسی است:getent passwd 1000
عدد ۱۰۰۰ را با UID واقعی مبدأ عوض کنید. اگر خروجی مثلاً حساب دیگری را نشان دهد، حفظ کورکورانه همان عدد ممکن است فایل را در اختیار کاربر اشتباه بگذارد. همین مقایسه را برای GID با
getent group انجام دهید.در صورتی که انتقال را قبلاً انجام داده‌اید، روی فایل نمونه در مقصد نیز
stat را اجرا و نتیجه دو سرور را مقایسه کنید. تفاوت صرفاً نام، عدد، یا هر دو را یادداشت کنید؛ راه‌حل هر حالت متفاوت است.۳. مشخص کنید چه چیزی باید حفظ شود
به‌طور پیش‌فرض، وقتی حفظ مالک و گروه فعال باشد، rsync تا جای ممکن نام کاربر و گروه را بین دو سرور تطبیق می‌دهد. اگر نامی در مبدأ یا مقصد قابل تطبیق نباشد، ممکن است به شناسه عددی بازگردد. گزینه
--numeric-ids به جای تطبیق نام‌ها، شناسه‌های عددی را منتقل می‌کند.سه تصمیم رایج وجود دارد:
۱. حساب‌ها از نظر نام واقعاً معادل‌اند: روش پیش‌فرض حفظ مالک می‌تواند مناسب باشد؛ مثلاً
alice هرچند UID متفاوتی دارد، در هر دو سرور همان حساب تأییدشده است.۲. شناسه‌ها عمداً در دو سیستم یکسان و متعلق به همان هویت هستند: ممکن است
--numeric-ids مناسب باشد؛ ابتدا UID و GID را در هر دو طرف برای همه گروه‌های مهم مقایسه کنید.۳. نام یا شناسه‌ها عمداً متفاوت‌اند: برای داده‌ای که مالک‌های متعدد دارد می‌توانید نگاشت مشخصِ کاربر و گروه تعریف کنید. برای پوشه‌ای که همه فایل‌هایش واقعاً باید متعلق به یک حساب باشد،
--chown می‌تواند همه را به همان حساب بدهد؛ این گزینه برای فایل‌های متعلق به چند مشتری یا چند سرویس مناسب نیست.برای حفظ مالک دلخواه، فرایند دریافت‌کننده معمولاً باید مجوز superuser داشته باشد؛ گروه نیز به مجوز مناسب نیاز دارد. اجرای rsync با
sudo فقط در مبدأ، به‌تنهایی به فرایند سمت مقصد مجوز تغییر مالک نمی‌دهد. در نمونه زیر انتقال از سمت مقصد آغاز می‌شود و حساب محلی مجاز، دریافت‌کننده را با sudo اجرا می‌کند.۴. اول در پوشه آزمایشی انتقال دهید
روی سرور جدید یک پوشه تازه بسازید. این دستور اگر نام از قبل وجود داشته باشد خطا می‌دهد؛ در آن صورت نام تازه‌ای انتخاب کنید:
کد / دستورsudo mkdir /srv/rsync-ownership-test
فرض می‌کنیم
backup@old-server یک حساب SSH مجاز است که به فایل‌های مبدأ دسترسی خواندن دارد و مسیر واقعی داده /srv/project-data/ است. نام میزبان، حساب و مسیر را متناسب با سامانه خود عوض کنید. کلید و اثرانگشت میزبان را از مسیر مطمئن تأیید کنید. چون دستور با sudo اجرا می‌شود، تنظیمات و کلیدهای SSH کاربر root در مقصد ممکن است با کاربر عادی شما فرق داشته باشد؛ بررسی کلید میزبان را خاموش نکنید.ابتدا فقط پیش‌نمایش بگیرید:
کد / دستورsudo rsync -aHAX --dry-run --itemize-changes -e ssh backup@old-server:/srv/project-data/ /srv/rsync-ownership-test/
-a حالت آرشیو و شامل حفظ مالک و گروه است؛ -HAX به‌ترتیب برای hard link، ACL و ویژگی‌های توسعه‌یافته است، در صورتی که نسخه‌ها و فایل‌سیستم‌ها از آن‌ها پشتیبانی کنند. --dry-run چیزی کپی نمی‌کند و --itemize-changes تغییرات پیشنهادی را نشان می‌دهد. اگر این ویژگی‌های اضافی را نیاز ندارید یا پشتیبانی نمی‌شوند، گزینه‌ها را با توجه به نیاز خود تغییر دهید. پیش‌نمایش به‌تنهایی موفقیت نوشتن و اعمال مالکیت واقعی را تضمین نمی‌کند.علامت
کد / دستور/ آخر مسیر مبدأ مهم است: با آن، محتوای پوشه به مقصد می‌رود. قبل از مرحله واقعی، مسیر مقصد، فهرست فایل‌ها و فضای آزاد را بررسی کنید:df -h /srv/rsync-ownership-test
اگر همه‌چیز درست است، همان انتقال را فقط برای پوشه آزمایشی بدون
کد / دستور--dry-run انجام دهید:sudo rsync -aHAX --itemize-changes -e ssh backup@old-server:/srv/project-data/ /srv/rsync-ownership-test/
پس از پایان، کد خروج باید صفر و گزارش بدون خطای دسترسی باشد. یک یا چند فایل را در مقصد با
stat -c '%n %U %u %G %g' /srv/rsync-ownership-test/example.txt بررسی کنید و نتیجه را با جدول هویت‌های مبدأ مقایسه کنید. اگر مالک باید همان نام با UID متفاوت باشد، نام مقصد باید به حساب درست اشاره کند. صرف دیدن نام مشابه بدون بررسی UID و هویت واقعی کافی نیست.۵. اگر باید عددها دقیقاً حفظ شوند
فقط وقتی تأیید کرده‌اید UID و GIDهای مبدأ در مقصد به صاحبان درست اشاره می‌کنند، برای آزمایش در پوشه تازه دیگری از این نمونه استفاده کنید:
کد / دستورsudo mkdir /srv/rsync-numeric-test
کد / دستورsudo rsync -aHAX --numeric-ids --dry-run --itemize-changes -e ssh backup@old-server:/srv/project-data/ /srv/rsync-numeric-test/
اگر پیش‌نمایش مناسب است، همان دستور را با حذف
--dry-run اجرا کنید و با ls -ln و stat روی فایل‌های نمونه کنترل کنید. این گزینه نام کاربران را جابه‌جا نمی‌کند؛ عدد را حفظ می‌کند. بنابراین اگر عدد ۱۰۰۰ در سرور جدید متعلق به شخص دیگری است، این روش می‌تواند دسترسی اشتباه ایجاد کند.۶. اگر نام حساب‌ها متفاوت است
فرض کنید فایل‌هایی که در مبدأ متعلق به
کد / دستورalice هستند، طبق تصمیم شما باید در مقصد متعلق به حساب موجود appuser شوند و گروه alice به appgroup نگاشت شود. ابتدا وجود حساب مقصد را بررسی کنید:getent passwd appuser
کد / دستورgetent group appgroup
بعد در یک مسیر آزمایشی تازه، نگاشت را پیش‌نمایش کنید:
کد / دستورsudo mkdir /srv/rsync-mapped-test
کد / دستورsudo rsync -aHAX --usermap='alice:appuser' --groupmap='alice:appgroup' --dry-run --itemize-changes -e ssh backup@old-server:/srv/project-data/ /srv/rsync-mapped-test/
اگر نسخه‌های rsync و فهرست فایل‌ها مناسب‌اند، مرحله آزمایشی را بدون
--dry-run اجرا و مالک نمونه‌ها را در مقصد کنترل کنید. این نگاشت فقط برای هویت مشخص‌شده است؛ هویت‌های دیگر همچنان نیاز به بررسی دارند. استفاده هم‌زمان از --numeric-ids با نگاشت نام‌محور رفتار را عوض می‌کند؛ در آن حالت باید بر اساس مستندات از عددهای مبدأ استفاده کنید. اگر rsync قدیمی گزینه نگاشت را نمی‌شناسد، نسخه آن را با rsync --version در هر دو سرور ببینید و قبل از انتقال روش سازگار انتخاب کنید.۷. پس از آزمایش، انتقال واقعی را کنترل کنید
تنها پس از تأیید مالک، گروه، مجوز و کارکرد برنامه در آزمایش، همان روش را برای مسیر مقصد واقعی با برنامه قطع یا همگام‌سازی مناسب به کار ببرید. از
--delete در انتقال اول استفاده نکنید؛ این گزینه می‌تواند فایل‌های موجود مقصد را حذف کند. برای مسیرهای حساس، ACL و ویژگی‌های امنیتی مقصد را هم بررسی کنید؛ در سیستم‌های SELinux، برچسب فایل باید با سیاست همان مقصد سازگار باشد.اگر در مقصد هنوز خطای
Operation not permitted دارید، اول ببینید دریافت‌کننده واقعاً چه مجوزی دارد و آیا فایل‌سیستم مقصد تغییر مالک، ACL و xattr را پشتیبانی می‌کند. اجرای chmod 777 یا تغییر مالک همه پوشه‌های سرور راه‌حل این مشکل نیست.در پایان با حساب برنامه، یک عملیات واقعی مثل خواندن فایل و نوشتن در پوشه مجاز را آزمایش کنید. فایل‌های مبدأ را تا زمان تأیید سلامت و نسخه پشتیبان پاک نکنید. اگر انتقال شبکه در میانه راه قطع شد، راهنمای ادامه انتقال بکاپ با rsync به درد می‌خورد.
این نکته‌ها در جابه‌جایی به سرور مجازی ایران یا سرور اختصاصی ایران یکسان‌اند؛ نوع دیسک و مجوزهای محیط مقصد همچنان باید جداگانه بررسی شوند. توضیح دقیق گزینه‌ها در راهنمای رسمی rsync آمده است.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام