‫Backup گیری از یک دیتابیس راه دور

فرض کنید به یک دیتابیس MS SQL Server راه دور فقط از طریق Management Studio دسترسی دارید. یعنی سرور هیچ راهی برای انتقال فایل برای ندارد. حالا شما می‌خواهید از دیتابیس مورد نظر backup بگیرید. راه معمول این است که از طریق Management Studio اقدام به Backup گیری کرده و سپس فایل bak مورد نظر را از درایو local سرور مربوطه به محل دلخواه خود کپی کنید. ولی حالا که دسترسی فایلی به سرور ندارید نمی‌توانید از این راه استفاده کرده و باید به فکر راه حل دیگری باشید.

بعضی از Data Centerها یک اینترفیس جداگانه برای کمک به این موضوع دارند. اما اگر این ابزار هم موجود نباشد چه باید کرد؟ بدتر از این تصور کنید دیتابیس مورد نظر از نوع Express بوده و دسترسی‌های شما در حداقل ممکن قرار داشته باشد. در این طور مواقع چند راه به ذهن می‌رسد.

۱- اسکریپت کردن دیتابیس و نگهداری اسکریپت‌ها به عنوان backup. من این راه رای برای یک دیتابیس SQL Express انجام دادم ولی جواب نگرفتم.

۲- استفاده از مکانیزم Export. خوشبختانه این راه را در مورد دیتابیس مورد قبل انجام دادم و جواب داد.

۳- کد نویسی و استفاده از Sql Server Management Object. من از این راه استفاده نکردم ولی خیلی به آن خوشبین نیستم. چون ظاهراً این کدها باید در همان ماشینی اجرا شوند که SQL Server در آن نصب است. خیلی از مواقع Database Server ما با Web Server یکی نیست.

۴- استفاده از راه حل خیلی خلاقانه‌ای که در این مقاله codeproject.com توضیح داده شده. در این راه حل هیچ نیازی نیست که برنامه backup گیری روی database server اجرا شود. می‌توان آن را روی کامپیوتر local غیر سرور خود اجرا کرد. روش این برنامه گرفتن backup روی خود سرور، ایجاد یک جدول دیتابیسی موقتی، insert کردن محتوای فایل backup در جدول موقتی، select معمولی از جدول موقتی و انتقال آن به کامپیوتر local و ذخیره آن به صورت یک backup واقعی! البته من با این که با یکی از قلق‌های این برنامه کنار آمدم ولی نتوانستم از آن استفاده واقعی بکنم. چون احتیاج به دسترسی bulk داشتم. هر چند که این روش برای من کار نکرد ولی خلاقیت آن مرا شگفت زده کرد. مطمئن هستم می‌توان با استفاده از راه حل های مشابهی مشکل دسترسی bulk را هم حل کرد.

‫چرا SVN بهتر از TFS است؟

دلایل خیلی زیادی برای این برتری وجود دارد. ولی فعلاً به این یکی بسنده کنید. فرایند پشتیبان‌گیری و برگرداندن پشتیبان‌ها (backup/restore) در svn خیلی ساده ولی در TFS خیلی پیچیده است.

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

اما در TFS 2010 شما باید به کلی از کارهای admin ویندوز و  Sql Server مسلط باشید و برای انجام یک restore ناقابل مراحل زیادی را طی کنید. اگر باور نمی‌کنید نگاهی به لینک‌های زیر که همگی مربوط به فرایند backup/restore در TFS 2010 است نگاهی بیندازید.

Backing up TFS 2010

While using TFS 2010 as the only repository of source code and project management repository for a company with more than 10 developer, it is very important to handle backup/restore plans as accurate as possible. As I needed to backup such a TFS server correctly, I have compiled a check list for myself that I’d like to share it with all.

1. DVD of softwares must be kept at a separate reachable place. Including  Windows Server 2008 R2, SQL Server 2008, TFS 2010, SharePoint and any original/modified template process like Scrum for Team System version 3’s x64 template process.

2. Know of any good online/offline documentation for backup/restore: Backing up and Restoring Your Deployment. Some good key points of this document are:
-Databases to backup: TFS_Configuration, TFS_Warehouse, TFS_CollectionName (all collections), TFS_Analysis (if any), ReportServer, ReportServerTempDB, WSS_Config (if any), WSS_Content (if any), WSS_AdminContent (if any)
-TFS_Configuration database must be last database to backup and first database to restore.

3. Backup the Reporting Services Encryption Key using “Reposrting Services Configuration Manager”.  It’s a tiny file. This file must be protected with a password. Don’t forget to write down the password for future use. Alternatively you can use a simple password like 123 so you never forget it.

4. Use this guidline for: Restore Data to the Same Location and use this for Restore a Single Server Deployment to New Hardware.

5. You can always use a virtual machine to test you backups.