تفاوت اسنپ‌شات، بک‌آپ و کلون در سرور مجازی (VPS)

تفاوت واقعی اسنپ‌شات، بک‌آپ و کلون

اسنپ‌شات VPS یک ایمیج دیسک از سرور شماست که توسط ارائه‌دهنده خدمات، روی زیرساخت همان ارائه‌دهنده و در حساب کاربری شما نگهداری می‌شود. بک‌آپ یک کپی مستقل از داده‌های شماست که می‌توانید آن را در جای دیگری بازیابی کنید، بدون اینکه نیازی به کمک ارائه‌دهنده‌ای باشد که نسخه اصلی را در اختیار داشته است. کلون یک نمونه (instance) جدید است که از روی یک اسنپ‌شات مستقر شده است؛ بنابراین، حیات خود را به عنوان یک کپی دقیق از نسخه اصلی، شامل هویت آن، آغاز می‌کند.

این موارد مشکلات متفاوتی را حل می‌کنند. اسنپ‌شات یک به‌روزرسانی ناموفق را در عرض چند دقیقه به حالت قبل بازمی‌گرداند، اما در صورت بسته شدن حساب کاربری، هیچ کمکی نمی‌کند. بک‌آپ در صورت از دسترس خارج شدن ارائه‌دهنده خدمات باقی می‌ماند، اما بازیابی آن زمان بیشتری می‌برد زیرا ابتدا باید ماشین را دوباره بسازید. کلون در یک مرحله یک سرور دوم در حال اجرا به شما می‌دهد و همچنین باعث می‌شود دو ماشین داشته باشید که هر دو تصور می‌کنند همان ماشین اصلی هستند.

چرا snapshot سرور مجازی (VPS) جایگزین نسخه پشتیبان (backup) نیست

مشکل در دامنه خرابی (failure domain) است، نه کیفیت تصویر (image). یک snapshot روی پلتفرم ذخیره‌سازی ارائه‌دهنده شما قرار دارد، معمولاً در همان منطقه‌ای (region) که سرور اصلی در آن است و همیشه در همان حساب کاربری. یک رویداد واحد می‌تواند هم سرور و هم snapshot آن را از بین ببرد.

• حساب کاربری تعلیق می‌شود، پرداخت ناموفق است یا شخصی اطلاعات ورود را سرقت می‌کند.
• یک شخص یا اسکریپت با دسترسی API، نمونه (instance) را حذف می‌کند. در بسیاری از ارائه‌دهندگان، حذف یک نمونه باعث حذف snapshotهای آن نیز می‌شود. پیش از آنکه فرض را بر غیر از این بگذارید، مستندات ارائه‌دهنده خود را مطالعه کنید.
• منطقه (region) دچار اختلال می‌شود و همه چیز در آن به‌طور همزمان غیرقابل دسترس می‌گردد.
• چیزی که با دسترسی root روی سرور اجرا می‌شود، توکن API ارائه‌دهنده را که در /root رها کرده‌اید پیدا می‌کند و پیش از دست‌کاری دیسک، snapshotها را حذف می‌کند.

نسخه پشتیبان (backup) کپی‌ای است که از هر چهار مورد بالا جان سالم به در می‌برد. آزمون این موضوع یک سوال ساده است: اگر حساب کاربری شما در ارائه‌دهنده همین امروز بعدازظهر از بین برود، چه چیزی را می‌توانید بازیابی کنید و کجا آن را بازیابی خواهید کرد؟ هر چیزی که در این آزمون شکست بخورد، صرفاً یک ابزار بازگشت به عقب (rollback) است. به گرفتن snapshot ادامه دهید، زیرا هیچ چیز سریع‌تر از آن بازیابی نمی‌شود. سپس یک کپی دوم روی فضای ذخیره‌سازی که تحت کنترل ارائه‌دهنده شما نیست، نگهداری کنید.

قانون قدیمی همچنان معتبر است: سه کپی از داده‌ها، روی دو نوع فضای ذخیره‌سازی، که یکی از آن‌ها خارج از پلتفرم باشد. یک snapshot ارائه‌دهنده به همراه یک مخزن پشتیبان restic روی زیرساخت مجزا این نیاز را با دو بخش مجزا پوشش می‌دهد.

چرا اسنپ‌شات گرفتن از دیتابیس در حال اجرا ممکن است منجر به خرابی شود

اسنپ‌شات‌های ارائه‌دهنده، دستگاه بلوکی (block device) را دقیقاً در همان لحظه‌ای که هست کپی می‌کنند. این فرآیند از برنامه‌های شما نمی‌خواهد که ابتدا متوقف شوند و هیچ دیدی نسبت به داده‌های موجود در page cache ندارد. بنابراین، تصویر نهایی در بهترین حالت crash-consistent است. این وضعیت دقیقاً مشابه حالتی است که کابل برق سرور ناگهان کشیده شود.

بیشتر اجزای سیستم این وضعیت را مدیریت می‌کنند. فایل‌سیستم‌های ext4 و XFS هنگام mount شدن، journal خود را بازپخش (replay) می‌کنند و بالا می‌آیند. PostgreSQL نیز در زمان شروع، write-ahead log خود را بازپخش می‌کند و لاگ‌ها نیز این موضوع را تأیید می‌کنند:

LOG:  database system was not properly shut down; automatic recovery in progress

موتور InnoDB نیز همین کار را انجام می‌دهد و در زمان شروع، خطوط مربوط به crash recovery خود را چاپ می‌کند. این بازیابی، رفتار استاندارد و طراحی‌شدهٔ دیتابیس است؛ بنابراین اسنپ‌شات تک‌ولومی از یک دیتابیس PostgreSQL یا MySQL که در لحظهٔ اسنپ‌شات بار کاری کمی دارد، معمولاً بدون مشکل بازیابی می‌شود.

مواردی که crash-consistent بودن کافی نیست، واقعی و دردسرساز هستند. اگر داده‌های شما روی دو ولوم پخش شده باشند، دیسک ریشه (root) و دیسک داده‌ها در لحظات متفاوتی اسنپ‌شات می‌شوند؛ در نتیجه فایل‌های داده و دایرکتوری لاگ با هم همخوانی ندارند و فرآیند بازیابی هیچ دادهٔ صحیحی برای بازپخش ندارد. هر فایلی که برنامه بدون فراخوانی fsync روی دیسک می‌نویسد، مانند یک فایل آپلود ناقص یا فایل صف، ممکن است به‌صورت ناقص (truncated) بازیابی شود. هر چیزی هم که برنامه در حافظه نگه داشته و قرار بوده طبق زمان‌بندی روی دیسک بنویسد، در تصویر اسنپ‌شات وجود نخواهد داشت.

بنابراین، پیش از گرفتن اسنپ‌شات، یک dump روی دیسک ذخیره کنید. در این صورت، تصویر نهایی شامل فایلی است که می‌دانید از نظر داخلی منسجم است، فارغ از اینکه وضعیت فایل‌های دادهٔ زنده در چه حالتی باشد.

sudo -u postgres pg_dumpall --clean --file=/var/backups/pg-$(date +%F).sql
sudo mysqldump --single-transaction --routines --all-databases > /var/backups/mysql-$(date +%F).sql

دستور --single-transaction یک dump منسجم از جداول InnoDB بدون مسدود کردن نویسنده‌ها تهیه می‌کند، زیرا این dump در قالب یک تراکنش repeatable-read اجرا می‌شود. این دستور جداول MyISAM را پوشش نمی‌دهد، چرا که آن‌ها نیاز به قفل کردن یا متوقف کردن سرور دارند. پیش از اعتماد به dump، بررسی کنید که خالی یا ناقص نباشد: tail -n 1 /var/backups/mysql-$(date +%F).sql در یک mysqldump کامل، با یک کامنت Dump completed به پایان می‌رسد.

اگر یک ولوم دادهٔ مجزا دارید، می‌توانید آن را برای چند ثانیه‌ای که اسنپ‌شات نیاز دارد، freeze کنید:

sudo fsfreeze -f /srv
# take the snapshot from your provider's panel or API
sudo fsfreeze -u /srv

فقط ولوم داده را freeze کنید. هرگز / را freeze نکنید. فریز کردن فایل‌سیستم ریشه، تمام عملیات نوشتن روی سیستم را مسدود می‌کند، از جمله شلی که قرار است دستور unfreeze را در آن تایپ کنید؛ در نتیجه خود را از سیستم قفل می‌کنید و مجبور به hard reset خواهید شد.

بخش خارج از سایت: restic یا Borg

اسنپ‌شات، بخش سریع کار است. کپی خارج از سایت (offsite)، بخشی است که در صورت بروز مشکل برای ارائه‌دهنده شما، باقی می‌ماند. restic یک گزینه پیش‌فرض مناسب است، زیرا عملیات deduplication را انجام می‌دهد، در سمت کلاینت رمزنگاری می‌کند و قابلیت نوشتن روی فضای ذخیره‌سازی شیء‌گرا (S3-compatible)، SFTP یا یک دایرکتوری ساده را دارد. استفاده از یک VPS ذخیره‌سازی به عنوان مقصد خارج از سایت در اینجا به‌خوبی عمل می‌کند، زیرا مخازن پشتیبان بیش از آنکه به IOPS نیاز داشته باشند، به ظرفیت ذخیره‌سازی نیاز دارند.

sudo apt update && sudo apt install -y restic
sudo sh -c 'umask 077; head -c 24 /dev/urandom | base64 > /root/.restic-pass'
sudo chmod 600 /root/.restic-pass
sudo cat /root/.restic-pass

همین حالا آن passphrase را در یک مدیریت‌کننده رمز عبور کپی کنید؛ روی دستگاهی که این سرور نباشد. مخزن restic بدون آن قابل باز شدن نیست و هیچ راهی برای بازیابی آن وجود ندارد. اگر تنها نسخه رمز عبور روی سیستمی باشد که به‌تازگی از دست داده‌اید، نسخه پشتیبان شما چیزی جز داده‌های رمزنگاری‌شده غیرقابل استفاده نخواهد بود.

export RESTIC_REPOSITORY="s3:https://s3.example.com/vps-backups"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
sudo -E restic init
sudo -E restic backup /etc /srv /var/backups
sudo -E restic snapshots

sudo -E این متغیرها را حفظ می‌کند، زیرا بدون آن، root یک محیط خالی دریافت می‌کند و restic گزارش می‌دهد که هیچ مکانی برای مخزن مشخص نشده است. restic snapshots باید اجرای اخیر شما را به همراه میزبان و مسیرهای آن فهرست کند. مخزن را طبق یک زمان‌بندی مشخص بررسی (verify) کنید و به‌جای بررسی صرف ساختار، بخشی از داده‌ها را بازیابی کنید تا از سلامت آن‌ها مطمئن شوید:

sudo -E restic check --read-data-subset=5%
sudo -E restic restore latest --target /tmp/restore-check
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

پشتیبانی که تست نشده باشد، فقط یک حدس است. حداقل یک‌بار عملیات بازیابی را روی یک VPS متفاوت انجام دهید، زمان آن را بگیرید و یادداشت کنید؛ چرا که آن عدد، هدف واقعی شما برای بازیابی (recovery target) است. Borg گزینه مطمئن دیگری است که مخزن خود را به‌جای فضای ذخیره‌سازی شیء‌گرا، از طریق SSH ذخیره می‌کند؛ تفاوت‌های این دو در مقایسه restic و BorgBackup بررسی شده است.

مواردی که باید پیش از انتقال یک VPS کلون‌شده به محیط عملیاتی اصلاح شوند

کلون یک کپی دقیق است. این ویژگی هم نقطه قوت آن است و هم مشکل‌ساز. هر چیزی که نسخه اصلی را منحصربه‌فرد می‌کرد، در اینجا تکرار شده است و این تکرارها با هم تداخل پیدا می‌کنند.

کلیدهای میزبان SSH را بازسازی کنید. کلون شامل فایل‌های /etc/ssh/ssh_host_* نسخه اصلی است، بنابراین دو سرور هویت میزبان یکسانی را ارائه می‌دهند. هر کسی که یکی از آن‌ها را کنترل کند، می‌تواند برای هر کلاینتی که آن کلید را پذیرفته است، خود را به جای دیگری جا بزند. SSH هیچ هشداری نمی‌دهد، زیرا کلید همان چیزی است که کلاینت انتظار دارد.

sudo rm -f /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart ssh
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

دستور ssh-keygen -A یک کلید جدید از هر نوعی که دیمون انتظار دارد، می‌نویسد. اثر انگشت (fingerprint) حاصل از آخرین دستور باید با اثر انگشت نسخه اصلی متفاوت باشد. نشست فعلی شما پس از راه‌اندازی مجدد باقی می‌ماند، زیرا راه‌اندازی مجدد sshd اتصالات برقرار شده را قطع نمی‌کند. این کار را پیش از آنکه کسی به کلون متصل شود، انجام دهید. اگر آن را به بعد موکول کنید، هر کلاینتی که قبلاً به کلید ارث‌بری‌شده اعتماد کرده بود، با WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! مواجه می‌شود و باید ابتدا ssh-keygen -R <host> را اجرا کند.

شناسه ماشین (machine ID) را بازنشانی کنید. /etc/machine-id یک شناسه منحصربه‌فرد است که systemd یک بار در اولین بوت تولید می‌کند و کلون آن را به ارث می‌برد.

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id
sudo reboot

یک فایل /etc/machine-id خالی به systemd می‌گوید که در بوت بعدی یک مقدار جدید تولید کند؛ به همین دلیل است که فایل را به جای حذف کردن، خالی (truncate) می‌کنید. وقتی این شناسه تکراری باشد، دو مورد دچار اختلال می‌شود. در ایمیج‌هایی که آدرس خود را از طریق DHCP می‌گیرند، systemd-networkd به‌طور پیش‌فرض شناسه کلاینت DHCP خود را از روی machine ID استخراج می‌کند، بنابراین هر دو کلون به عنوان یک کلاینت واحد درخواست دریافت lease می‌کنند و سرور به هر دو آدرس یکسانی می‌دهد. همچنین journald هر ورودی را با machine ID مهر می‌زند، بنابراین یک جمع‌کننده لاگ مرکزی، هر دو سرور را تحت یک ماشین ثبت می‌کند. پس از راه‌اندازی مجدد، cat /etc/machine-id را اجرا کنید و تغییر مقدار را تأیید کنید.

نام میزبان (hostname) را تغییر دهید.

sudo hostnamectl set-hostname web-02
grep 127.0.1.1 /etc/hosts

دستور hostnamectl فایل /etc/hostname را می‌نویسد و نام را بلافاصله اعمال می‌کند. این دستور فایل /etc/hosts را تغییر نمی‌دهد، بنابراین خط 127.0.1.1 را ویرایش کنید تا با نام جدید مطابقت داشته باشد. اگر این کار را انجام ندهید، نام جدید در هیچ‌جا resolve نمی‌شود و هر فراخوانی sudo منتظر یک lookup ناموفق می‌ماند و sudo: unable to resolve host web-02: Name or service not known را چاپ می‌کند.

تمام اعتبارنامه‌هایی که در ایمیج تعبیه شده‌اند را تغییر دهید (Rotate). کلون حاوی اسرار نسخه اصلی است و اکنون دو ماشین می‌توانند به عنوان نسخه اصلی عمل کنند. فایل‌های authorized_keys مربوط به SSH، توکن‌های API ارائه‌دهنده و DNS، فایل‌های .env برنامه‌ها، رمزهای عبور دیتابیس، کلیدهای خصوصی TLS، توکن‌های ثبت‌نام مانیتورینگ و رمز عبور مخزن restic را بررسی کنید. دستور زیر اکثر آن‌ها را پیدا می‌کند:

sudo grep -rIlE 'PASSWORD|SECRET|TOKEN|API_KEY' /etc /srv /opt /home 2>/dev/null
sudo find / -name '.env' -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

اگر کلون یک نسخه آزمایشی است که هرگز ترافیک عملیاتی دریافت نخواهد کرد، به جای تغییر (rotate)، آن‌ها را ابطال (revoke) کنید. یک محیط staging که دارای توکن API عملیاتی است، در واقع یک محیط عملیاتی با وصله‌های امنیتی ضعیف‌تر است.

وظایفی که اکنون دو بار اجرا می‌شوند را غیرفعال کنید. دو سروری که crontab یکسانی را اجرا می‌کنند، در یک دقیقه مشخص به سیستم‌های خارجی یکسانی ضربه می‌زنند.

systemctl list-timers --all
sudo crontab -l
sudo ls -l /etc/cron.d /etc/cron.daily

مورد restic ارزش توضیح بیشتری دارد، زیرا به جای اینکه فقط با صدای بلند شکست بخورد، سیاست نگهداری (retention) شما را خراب می‌کند. restic هر snapshot را با نام میزبان برچسب‌گذاری می‌کند و restic forget --keep-daily 7 سیاست خود را بر اساس هر میزبان اعمال می‌کند. دو ماشینی که نام میزبان یکسانی را گزارش می‌دهند، به عنوان یک میزبان واحد در نظر گرفته می‌شوند، بنابراین هفت snapshot "روزانه" ممکن است همگی از کلون بیایند در حالی که snapshotهای نسخه اصلی حذف می‌شوند. پیش از اولین اجرای پشتیبان‌گیری، نام میزبان را اصلاح کنید یا تایمر را در کلون متوقف کنید. مورد certbot ساده‌تر است: دو سروری که نام‌های یکسانی را تمدید می‌کنند، به محدودیت نرخ صدور گواهی تکراری مرجع صدور گواهی (CA) برخورد می‌کنند و اجرای ناموفق با خطایی مبنی بر صدور تعداد بیش از حد گواهی برای آن مجموعه نام خاص مواجه می‌شود. کلونی که دامنه آن هنوز به نسخه اصلی اشاره دارد، به هر حال نمی‌تواند چالش HTTP را پشت سر بگذارد، بنابراین تمدید را در آنجا غیرفعال کنید.

وضعیت عامل مانیتورینگ را مدیریت کنید. اکثر عامل‌ها (agents) خود را با نام میزبان یا یک فایل شناسه که در زمان نصب نوشته شده است شناسایی می‌کنند، بنابراین دو عاملی که به عنوان یک میزبان گزارش می‌دهند، معیارهای خود را در یک سری زمانی واحد ترکیب می‌کنند. نمودارهای CPU مقادیری را نشان می‌دهند که هیچ ماشین واحدی تولید نکرده است و هشدارها دچار نوسان (flap) می‌شوند. عامل را در کلون متوقف و حذف کنید، یا آن را با استفاده از روش مستندشده توسط فروشنده، تحت نام میزبان جدید دوباره ثبت‌نام کنید.

پیکربندی شبکه را برای آدرس نسخه اصلی بررسی کنید. اگر ایمیج دارای یک آدرس ثابت در netplan باشد، کلون ادعای مالکیت IPای را می‌کند که متعلق به ماشین دیگری است.

ip -br addr
sudo grep -r addresses /etc/netplan/

اگر این کلون قرار است به یک قالب (template) تبدیل شود، وضعیت cloud-init را پاک کنید.

sudo cloud-init clean --logs

این کار وضعیت cloud-init را در مسیر /var/lib/cloud حذف می‌کند، بنابراین بوت بعدی دوباره ماژول‌های اولین بوت را اجرا می‌کند که شامل تولید کلیدهای میزبان SSH در صورت عدم وجود آن‌هاست. برخی نسخه‌ها پرچمی برای بازنشانی machine ID نیز ارائه می‌دهند. به جای اعتماد به لیست پرچم‌های منابع دیگر، cloud-init clean --help را روی ایمیج خود اجرا کنید تا ببینید نسخه شما از چه چیزی پشتیبانی می‌کند.

چه زمانی از کدام روش استفاده کنیم

بازگردانی یک ارتقای پرخطر: از snapshot استفاده کنید. چند دقیقه پیش از اعمال تغییرات، یک snapshot بگیرید، ارتقا را اجرا کنید و در صورت بروز مشکل، تصویر (image) را بازیابی کنید. بازیابی، تمام داده‌های نوشته‌شده پس از snapshot را حذف می‌کند؛ بنابراین اگر سرور ترافیک زنده دریافت می‌کند، ابتدا از دیتابیس dump بگیرید و دقیقاً بدانید چه بازهٔ زمانی از داده‌ها را از دست خواهید داد. برای یک do-release-upgrade روی سروری که می‌توانید آن را برای ده دقیقه از دسترس خارج کنید، snapshot تمام چیزی است که نیاز دارید.

مهاجرت به پلن بزرگ‌تر: یک clone مستقر کنید. clone را از روی snapshot در پلن بزرگ‌تر بسازید، لیست هویت‌های ذکرشده در بالا را بررسی کنید و پیش از انتقال ترافیک، آن را روی IP اختصاصی خودش تست کنید. مقدار TTL در DNS را از یک روز قبل کاهش دهید تا جابه‌جایی سریع انجام شود و سرور اصلی را تا زمانی که سرور جدید ترافیک واقعی را بدون مشکل تحمل نکرده است، روشن نگه دارید. ابتدا با استفاده از روش بنچمارک یکسان روی هر دو سرور تأیید کنید که پلن بزرگ‌تر واقعاً برای بار کاری شما سریع‌تر است، زیرا vCPU بیشتر روی سخت‌افزار شلوغ‌تر، همیشه به معنای ارتقا نیست.

ساخت یک قالب (template): از یک ماشین پاک‌سازی‌شده snapshot بگیرید. یک سرور را نصب و ایمن‌سازی کنید، سپس پیش از گرفتن تصویر، تمام موارد منحصربه‌فرد را حذف کنید. هیچ host key، یک machine ID خالی، هیچ authorized_keys شخصی، هیچ اعتبارنامه‌ای و cloud-init پاک‌سازی‌شده. از آن snapshot بگیرید. هر نمونه‌ای که از این قالب مستقر شود، در اولین بوت هویت اختصاصی خود را تولید می‌کند، بنابراین چک‌لیست بالا دیگر نیازی به تکرار نخواهد داشت. آن را با ده دقیقه اول استاندارد روی یک VPS جدید ترکیب کنید تا قالب از قبل شامل کارهایی باشد که در غیر این صورت مجبور بودید تکرار کنید.

FAQ

آیا snapshot سرور مجازی (VPS) یک نسخه پشتیبان محسوب می‌شود؟

خیر، زیرا این snapshot در همان دامنه خرابی (failure domain) سرور اصلی قرار دارد. snapshot روی فضای ذخیره‌سازی ارائه‌دهنده خدمات شما، در حساب کاربری شما و معمولاً در همان منطقه جغرافیایی ذخیره می‌شود. تعلیق حساب کاربری، سرقت یک API key یا حذف تصادفی instance می‌تواند منجر به حذف همزمان سرور و snapshotهای آن شود؛ در بسیاری از ارائه‌دهندگان، حذف instance به‌طور پیش‌فرض باعث حذف snapshotهای آن نیز می‌گردد. snapshot سریع‌ترین راه برای بازگشت به وضعیت قبلی است، بنابراین از آن استفاده کنید، اما یک نسخه دوم رمزنگاری‌شده را در زیرساختی که تحت کنترل ارائه‌دهنده فعلی شما نیست، نگهداری کنید.

آیا پیش از گرفتن snapshot باید دیتابیس را متوقف کنم؟

همیشه خیر، اما باید پیامدهای آن را بپذیرید. snapshot ارائه‌دهنده خدمات، crash-consistent است؛ یعنی تصویر دیسک دقیقاً مشابه وضعیتی است که پس از قطع ناگهانی برق ایجاد می‌شود. PostgreSQL و InnoDB هنگام شروع کار، خود را از این وضعیت بازیابی می‌کنند و PostgreSQL در حین این فرآیند لاگ database system was not properly shut down; automatic recovery in progress را ثبت می‌کند. اگر داده‌های شما روی دو volume پخش شده باشد که در لحظات متفاوتی snapshot شده‌اند، یا اگر برنامه بدون fsync داده‌ها را بنویسد، بازیابی تضمین‌شده نیست. ابتدا یک pg_dumpall یا mysqldump --single-transaction روی دیسک بنویسید تا تصویر نهایی شامل فایلی باشد که از سلامت آن اطمینان دارید.

چرا دو سرور کلون‌شده بر سر یک آدرس IP با هم تداخل دارند؟

زیرا آن‌ها از /etc/machine-id مشترک استفاده می‌کنند. در ایمیج‌هایی که از DHCP استفاده می‌کنند، systemd-networkd به‌طور پیش‌فرض شناسه کلاینت DHCP را از machine ID می‌سازد؛ بنابراین هر دو کلون به عنوان یک کلاینت واحد درخواست lease می‌دهند و سرور DHCP به هر دو یک آدرس مشابه اختصاص می‌دهد. فایل /etc/machine-id را با صفر کردن محتوا پاک کنید، /var/lib/dbus/machine-id را حذف نمایید، آن را به /etc/machine-id لینک (symlink) کنید و سیستم را reboot کنید تا systemd مقدار جدیدی تولید کند. دلیل رایج دیگر، وجود آدرس استاتیک در /etc/netplan/ است که کلون آن را عیناً کپی کرده است؛ این مورد را با ip -br addr بررسی کنید.

سریع‌ترین راه برای اطمینان از آماده بودن یک کلون برای محیط تولید چیست؟

چهار مورد را با سرور اصلی مقایسه کنید. دستور ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub را روی هر دو اجرا کنید و تفاوت اثر انگشت‌ها (fingerprints) را تأیید کنید. دستور cat /etc/machine-id را روی هر دو اجرا کنید و تفاوت مقادیر را بررسی کنید. دستور hostnamectl status را اجرا کنید و مطمئن شوید نام سرور جدید است و به درستی resolve می‌شود تا sudo هشداری ندهد. سپس systemctl list-timers --all را اجرا کنید و تمام تایمرهایی که با یک سیستم مشترک در ارتباط هستند (مانند پشتیبان‌گیری، تمدید گواهی یا عامل‌های مانیتورینگ) را متوقف کنید تا مشخص شود کدام ماشین مسئولیت آن وظیفه را بر عهده دارد.