ویرگول
ورودثبت نام
Content Creator
Content Creator
Content Creator
Content Creator
خواندن ۱۰ دقیقه·۱ ماه پیش

سرور جدید؛ اطلاعات شرکت را چگونه منتقل کنیم؟

انتقال اطلاعات به سرور جدید با نظارت کارشناس در اتاق سرور
انتقال اطلاعات به سرور جدید با نظارت کارشناس در اتاق سرور

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

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

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

اول مشخص کنید چه چیزهایی منتقل می‌شوند

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

برای انتقال اطلاعات به سرور جدید، کنار نام هر سرویس این موارد را ثبت کنید:

  • مسیر داده‌ها، حجم فعلی و میزان تغییر روزانه آن‌ها.

  • نسخه سیستم‌عامل، نرم‌افزار و موتور پایگاه داده.

  • کاربران، گروه‌ها، حساب‌های سرویس و سطح دسترسی آن‌ها.

  • مسیرهای اشتراکی، تنظیمات شبکه و اتصال به سرویس‌های دیگر.

  • وظایف زمان‌بندی‌شده، تنظیمات بکاپ و وضعیت لایسنس‌ها.

  • مسئول تایید عملکرد هر نرم‌افزار پس از جابه‌جایی.

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

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

سازگاری سرور مقصد را پیش از اجرا بررسی کنید

در انتخاب سخت‌افزار برای انتقال اطلاعات به سرور جدید، نسخه نرم‌افزارهای فعلی را در نظر بگیرید. یک برنامه قدیمی ممکن است برای سیستم‌عامل جدید تایید نشده باشد. وضعیت درایورها، پشتیبانی سیستم‌عامل و سازگاری مجازی‌ساز با مدل دقیق سخت‌افزار هم باید بررسی شود. HPE برای این بررسی ماتریس‌های پشتیبانی و سازگاری منتشر می‌کند؛ نتیجه را برای مدل و نسخه مورد استفاده خودتان کنترل کنید.

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

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

بکاپ را پیش از مهاجرت بازیابی کنید

پیش از انتقال اطلاعات به سرور جدید، یک نسخه پشتیبان مستقل تهیه کنید و بازیابی آن را در محیط آزمایشی انجام دهید. وجود فایل بکاپ یا پیام موفقیت نرم‌افزار کافی نیست؛ باید بتوانید داده را بازیابی کنید و نتیجه را بررسی کنید. راهنمای CISA هم بر نگهداری بکاپ آفلاین و رمزگذاری‌شده و آزمون منظم بازیابی تاکید دارد.

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

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

روش انتقال را بر اساس نوع سرویس انتخاب کنید

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

فایل‌سرور و پوشه‌های مشترک

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

مایکروسافت در مستندات Storage Migration Service، مراحل شناسایی، انتقال داده و در صورت نیاز، انتقال هویت سرور را توضیح می‌دهد. این ابزار در محیط‌های پشتیبانی‌شده برای انتقال فایل، اشتراک‌ها و تنظیمات امنیتی کاربرد دارد. دامنه استفاده و محدودیت‌های آن باید بررسی شود؛ مهاجرت همه نقش‌های یک سرور را پوشش نمی‌دهد.

پایگاه داده و نرم‌افزارهای حسابداری

برای انتقال اطلاعات به سرور جدید در محیط SQL Server، بکاپ و بازیابی یکی از روش‌های مستند است. سازگاری نسخه مبدا و مقصد اهمیت دارد؛ برای مثال، بکاپ SQL Server 2022 به صورت مستقیم روی SQL Server 2019 بازیابی نمی‌شود. روش مناسب را با مسئول پایگاه داده و پشتیبان نرم‌افزار تعیین کنید.

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

ماشین‌های مجازی

اگر سرویس‌ها داخل ماشین مجازی اجرا می‌شوند، روش انتقال به مجازی‌ساز و نسخه‌های مبدا و مقصد وابسته است. در Hyper-V، نسخه پیکربندی ماشین و تنظیمات شبکه از موارد بررسی هستند. انتقال یک فایل دیسک مجازی به تنهایی تمام تنظیمات ماشین را همراه نمی‌برد.

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

یک انتقال آزمایشی انجام دهید

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

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

خطاها، مدت هر مرحله و اصلاحات لازم را ثبت کنید. این یادداشت‌ها در تعیین زمان توقف و ترتیب اجرا به کار می‌آیند. معیار پذیرش را هم از همین مرحله بنویسید؛ عبارت «سرور روشن شد» معیار کافی برای تحویل سرویس نیست.

بررسی فایل‌های بازیابی‌شده از بکاپ پیش از مهاجرت سرور شرکت
بررسی فایل‌های بازیابی‌شده از بکاپ پیش از مهاجرت سرور شرکت

زمان توقف را با فعالیت شرکت هماهنگ کنید

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

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

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

در انتقال نهایی، محل ثبت داده را مشخص کنید

وقتی مبدا و مقصد همزمان داده‌های متفاوت دریافت کنند، تشخیص نسخه معتبر سخت می‌شود. برای مرحله نهایی، روش کنترل تغییرها را طبق الزامات سرویس تعیین کنید: توقف ثبت اطلاعات، قرار دادن سرویس در حالت نگهداری یا استفاده از سازوکار همگام‌سازی پشتیبانی‌شده.

انتقال اطلاعات به سرور جدید باید یک نقطه مشخص برای تغییر دسترسی کاربران داشته باشد. قبل از آن، داده مبدا مرجع است؛ بعد از تایید و شروع کار، داده مقصد مرجع خواهد بود. ثبت این نقطه در برنامه، مسئولیت تیم اجرا و کاربران را روشن می‌کند.

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

برنامه بازگشت باید داده‌های تازه را پوشش بدهد

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

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

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

تحویل سرویس را با کار واقعی کاربران بسنجید

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

برای تحویل پروژه، نتیجه این موارد را ثبت کنید:

  • کارکرد نرم‌افزارهای اصلی و تایید کاربران مسئول.

  • صحت فایل‌ها و داده‌های مهم با روش متناسب با هر سرویس.

  • درستی دسترسی‌ها و نبود مجوزهای اضافی.

  • اجرای وظایف زمان‌بندی‌شده و اتصال سرویس‌های وابسته.

  • موفقیت بکاپ محیط جدید و آزمون بازیابی آن.

  • ثبت تغییرات، مسئول پشتیبانی و وضعیت سرور قبلی.

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

برای سرور مقصد چه اطلاعاتی به تامین‌کننده بدهیم؟

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

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

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

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

منابع فنی برای بررسی روش اجرا

  • راهنمای Microsoft درباره Storage Migration Service برای محدوده کاربرد ابزار و مراحل انتقال فایل‌سرور.

  • راهنمای Microsoft درباره انتقال دیتابیس با بکاپ و بازیابی برای بررسی سازگاری نسخه‌ها و تنظیمات وابسته.

  • راهنمای CISA درباره حفاظت و بازیابی بکاپ برای نگهداری نسخه پشتیبان و آزمون بازیابی.

سروربکاپشبکه
۰
۰
Content Creator
Content Creator
بررسیش کن
بررسیش کن
بررسیش کن مجله است برای معرفی و بررسی وسایل دیجیتال
شاید از این پست‌ها خوشتان بیاید