Showing posts with label Backup. Show all posts
Showing posts with label Backup. Show all posts

1 Aug 2013

Moving Exec Backup to new server

http://www.symantec.com/connect/blogs/backup-exec-install-blog-upgrades

So, your backup server is a few years old and you find yourself in need of a newer, bigger, better, faster one. Just one problem, you want/need to keep your data from Backup Exec for compliance reasons. You have the perfect server that is ready to take on this new role. It is some new 64 bit monster with Windows 2008 R2, tons of I/O capacity, memory, disk space and more. Then you ask yourself, how do I move Backup Exec’s data from the old server to the new server and keep everything in working order? Time to check the technote database! So you head off to http://support.symantec.com and start doing some queries. You may find this technote:
How to migrate (move) Backup Exec from one system to another with the same version of BE, Windows and same or different computer names.
http://www.symantec.com/business/support/index?page=content&id=TECH67768
In the last 10 years, there have been many who have followed this technote, for just this purpose. When you start reading it, there are some bold statements, and some restrictions. However, lets first review some of the components this technote will cover.
  1. The Backup Exec Database (BEDB).
  2. The Backup Exec Data (Job histories stored on disk, reports, and more).
  3. The Backup Exec Catalogs (Catalog folder on disk).
Today the SQL instance that hosts the BEDB is Microsoft SQL Server Express 2005 SP3. This version happens to be a 32 bit version when installed on either a 32 bit server, or on a 64 bit server. That is good news for customers who want to migrate from 32 bit operating systems, to 64 bit operating systems. That means there is really no difference in the database mounted on a 32bit OS, or a 64 bit OS, so you can carry it forward to a 64 bit OS without any compatibility issues. Furthermore, the Backup Exec Data and Catalogs on disk are files that are obviously transferrable between OS’s as well. The technote above is written to help move these three items between an old and new server. However, there are a few remaining items to consider.
One of the main items to consider is the configuration of the old and new server. The steps in the technote guide you through creating a matching configuration on the new server. If it is the same operating system as the previous install, then the same components and configuration items for that operating system will get laid down by the install. This should give a relatively similar configuration. The restriction at the top of the technote mentions operating systems of different versions. This is most likely for customers who tried to go backwards. Some examples where this would be broken would be:
  1. Customer installed the Deduplication option on Windows Server 2008 (64 bit), then tries to move to Windows 2008 (32 bit). This option does not install the same on Windows 2008 (32 bit), so this will cause issues.
  2. Customer has Microsoft Exchange (64 bit). Tries to move their data back to a Windows Server 2003 (32 bit) machine. Selections lists in the database would fail to protect these servers since they require tools that can only be present on a 64 bit machine. 
These are just a couple examples of how this could lead to possible compatibility/supportability issues. There may also be additional issues when migrating from 32 bit to 64 bit operating systems of different operating system versions, though I am not personally aware of any. I know of customers who have successfully migrated this way, but it not a supported upgrade path as is called out in this technote:
How to migrate Backup Exec to another server with a different Windows OS version.
http://www.symantec.com/business/support/index?page=content&id=TECH129826
There is also the added difficulty of having to move to a newer version of the product, and not being able to upgrade to the current version. Here is an example. A customer has Backup Exec 12.5 installed on a Windows 2000 Server. They would like to migrate to Backup Exec 2010 R3. However, Backup Exec 2010 R3 does not support installing on Windows 2000. In a situation like this, the only upgrade path is the following technote:
How to use BEMIG to manually upgrade the Backup Exec database from a previous version
http://www.symantec.com/business/support/index?page=content&id=TECH50537
Again this technote lists similar restrictions as the previous technote. Most if not all of the restrictions have very valid reasoning. Primarily because of the work that is done during the install, with respect to these items. The Backup Exec Installation will often make some database changes in coordination with the migration scripts. It’s a carefully orchestrated flow to carry the configuration forward to the new version. Trying the steps in the technote against a server that meets the restrictions will be hit or miss. Mostly depending on the database version being migrated, and changes made in each version of the product after that version. For example, trying to migrate a database that is from the 12.5 product, using the migration(BEMIG) scripts in our 2010 R3 release will yield failures when the “Shared Storage Option” is installed. This is because the install does some of the work, and the scripts do the rest of the work during the migration sequence. The only reliable way to get upgraded when you meet the restrictions is through operating system upgrades, and the supported Backup Exec Install upgrade paths. Now, if you don’t meet the restrictions, then you are essentially using the migration scripts in the newer version of the product, to migrate your database to the new version. This is the same sequence that the Backup Exec Installer uses to migrate the database between versions. However, you should also be careful that the old configuration and new configuration match as closely as possible. Doing so will save you many hours of frustration and issues that could be avoided!
Another question I received, asked about lingering server/devices post upgrade, that are un-removable in the Backup Exec 2010 UI. This issue may happen when migrating to a server with a different server name and different hardware. It’s a difficult issue to solve for our support team, and usually requires their intervention to fully remove. For this reason, it is recommended that you migrate to a server with the same name, and similar configuration. It saves many hours of resolving configuration issues when you do. If you decide change your server name, you will not be able to carry forward a deduplication folder, or its associated jobs. You may also decide to recreate your selection lists for proper viewing. There may even be more items you find needing your attention when you do. Save yourself the headache and keep the same server name. Follow the technote and copy the data to the network, take the server offline, bring up the new server with the same name, and finish followng the technote. You will be glad you did!

6 Dec 2011

DPMRA can not start with error 1168

Verify you COM+ rights for the DPM agent. It could be that there is a missmatch in the rights.
Click START / Administrative Tools / Component Services
Expand Component Services / Computers / My Computer / DCOM Config
Right click on the "DPM RA Services" and choose properties. Verify that under the Security tab / Launch and Activation Permissions you got Customize marked, click the Edit... button in the ACL you should see the computer account for your DPM server. If it's not present add it and mark all allow boxes and try to start the service again.

DPMRA stops more frequently

http://www.microsoft.com/download/en/confirmation.aspx?id=23224

21 Mar 2010

Restore System State by Veritas Exec Backup 10d

Sympton:
An "Access denied" error is received, and the system goes to Unavailable and cannot be chosen as a restore target during the restore of System State on an Active Directory server.

Details:
After submitting a restore of System State for an Active Directory server, the job starts and if necessary it moves the appropriate "System State.dat" file back to the business server. The recovery part of the restore of system state fails because Active Directory is online and the following alert is returned:

"In order to complete the restore of System State information, restart the computer in Directory Services Restore Mode and run Symantec DSRM System State Restore." The restore job then completes.

This step is normal and MUST be run with the business server in "normal" mode (not Directory Services Restore Mode) so that communications between the business server and the Continuous Protection server work as expected. At this point in time the correct "System State.dat" file is on the business server and other system state jobs are prevented from running, which stops the correct "System State.dat" file from being overwritten. You would see the following alert if another system state backup job is submitted:

"CPS is unable to backup System State while a DSRM restore of System State is pending."
Note: Non-system state jobs should run without any problem.

To continue the recovery, follow these steps:

1. Reboot the business server and enter Directory Services Restore Mode.
2. Login as the "Administrator"
3. Navigate to "C:\Program Files\VERITAS\Continuous Protection Server" (or wherever CPS is installed ) with Windows Explorer.
4. Locate the file "Symantec DSRM System State Restore.bat" and launch the file by double-clicking on it. The restore is started again, but this time it will succeed because the machine is in DSRM and no communications with any other CPS component is required.
Once the restore completes the window closes and the batch file is deleted.
5. Reboot the computer, but do not enter DSRM and the "restored" system state information will be "active".

http://seer.entsupport.symantec.com/docs/278653.htm


How to perform a restore of an Active Directory Domain Controller using Backup Exec Continuous Protection Server (CPS)


How to perform a restore of an Active Directory Domain Controller using Backup Exec Continuous Protection Server (CPS)

http://seer.entsupport.symantec.com/docs/278898.htm

Details:

To restore an Active Directory Domain Controller, perform the following steps:

1. Do NOT boot into Directory Services Restore Mode (DSRM), on the navigation bar select Restore.
2. In the task pane, select the computer.
3. In the selections pane, select the System State files.
4. In the task pane, under Restore Task, select Restore Files.
5. Define the appropriate options: Job Name, Description.
6. Click OK.
7. Click OK to clear the confirmation message.
8. The Job should complete with an alert "Unable to restore System State." The alert displays the following dialog, "In order to complete the restore of System State information, restart the computer in Directory Services Restore Mode and run Symantec DRSM System State restore."
9. At this point, boot the system into Directory Service Restore Mode.
10. Enter the DSRM password and log into the system.
11. On the desktop there will be a batch file named Symantec DRSM System State restore.dat, run it by double-clicking on it.
12. A command window will appear and the restore will begin.
13. After the restore has completed the command box will disappear, and a reboot countdown dialog will be displayed.

At this point, follow the steps in the following technote to use FixServer:
http://support.veritas.com/docs/277853
This will eliminate the duplicate entries of the business server in the Servers folder.

http://support.veritas.com/docs/277853

13 Mar 2010

Backup và Restore Exchange 2003 với Recovery Storage Group

Backup và Restore Exchange 2003 với Recovery Storage Group

Mọi quản trị viên hệ thống Exchange cần phải có một phương pháp khôi phục dữ liệu tối ưu để có thể sử dụng trong trường hợp máy chủ bị lỗi hay tình cờ xóa đi các email.
Backup và Restore Exchange 2003 với Recovery Storage Group
Bài viết này sẽ hướng dẫn các bạn một phương pháp khác đó là sử dụng kết hợp Recovery Storage Group với một công cụ backup và restore. Cụ thể chúng ta sẽ đi tìm hiểu phương pháp cài đặt Recovery Storage Group trong Exchange Server 2003 và sử dụng chúng để khôi phục các email cũng như hòm thư. Bạn có thể sử dụng công cụ này để thực hiện backup trước khi nâng cấp hệ thống Exchange Server 2003 lên Exchange Server 2007.

Giả sử bạn với vai trò là một quản trị viên hệ thống Exchange Server gặp phải hai tình huống sau: Khi đi nghỉ bạn nhận được yêu cầu từ người quản lý yêu cầu quay trở lại công ty để khôi phục lại một email đã bị xóa cách đây hai tháng. Email này đã được xóa bởi chính sách khôi phục những mục xóa.Tuy nhiên, sau khi bạn trở lại công ty thì hệ thống Exchange đã bị sập hai ngày trước đó, gây lỗi một số hòm thư hay tự động xóa một số lượng mail lớn của một số người dùng.

Bạn không nên quá lo lắng vì nếu đã lên lịch backup cho máy chủ thì bạn có thể dễ dàng tìm lại những thông tin này.

Recovery Storage Group khá hữu dụng, nó cho phép người dùng khôi phục dữ liệu trực tiếp mà không gây gián đoạn phiên làm việc của end user.

Lưu ý: Ít nhất bạn phải cài đặt bản Exchange Server 2003 Service Pack 1 (SPI) để có thể truy cập vào công cụ Recovery Storage Group.

Một số công cụ backup và restore thường được các quản trị viên sử dụng bao gồn: NTBACKUP, Symantec Backup Exec, EMC Retrospect hay CA ArcServe Backup, … Bài viết này sẽ kết hợp sử dụng Recovery Storage Group với Symantec Backup Exec 11d.

Cài đặt một Exchange Recovery Storage Group

Để sử dụng công cụ Recovery Storage Group bạn cần thực hiện các thao tác sau:

1. Mở Exchange System Manager rồi tìm trong nhóm quản trị cho đến khi thấy đối tượng máy chủ chứa thông tin lưu trữ mà bạn muốn khôi phục dữ liệu từ đó.

2. Phải chuột cào máy chủ này rồi chọn New | Recovery Storage Group như trong hình 1. Đảm bảo rằng bạn thực hiện thao tác này trong cùng nhóm quản trị chứa dữ liệu gốc. bạn không thể sử dụng phương pháp này để khôi phực dữ liệu giữa nhiều nhóm quản trị khác nhau.



Hình 1: Click vào đối tượng máy chủ để tạo mới Recovery Storage Group.
3. Để bổ sung một cơ sở dữ liệu để khôi phục, phải chuột vào Exchange Storage Group mới tạo rồi chọn Add New Database to Recover như trong hình 2. Màn hình tiếp theo sẽ hiển thị một danh sách vùng lưu trữ hòm thư hòm thư trên máy chủ này.



Hình 2: Bổ sung cơ sở dữ liệu muốn khôi phục.
4. Lựa chọn vùng lưu trữ chứa những hòm thư cần khôi phục rồi nhấn OK.



Hình 3: Lựa chọn cơ sở dữ liệu muốn khôi phục.
Lưu ý: Mặc định vùng lưu trữ hòm thư này bị gỡ bỏ như trong hình 4.



Hình 4: Mặc định vùng lưu trữ hòm thư này bị gỡ bỏ trong folder Recovery Storage Group.
5. Để xem thuộc tính của vùng lưu trữ này, bạn hãy phải chuột lên nó rồi chọn Properties. Cơ sở dữ liệu Recovery Group sẽ nằm trong thư mục riêng trong file hệ thống. Mặc định tùy chọn This database can be overwritten by a restore (Cơ sở dữ liệu này có thể bị một vùng lưu trữ ghi đè) đã được kích hoạt (hình 5).


Hình 5: Cửa sổ thuộc tính của vùng lưu trữ hòm thư.
6. Khi sử dụng phần mềm backup, bạn có thể chạy tiến trình khôi phục trên những thông tin lưu trữ hay những hòm thư riêng biệt chứa dữ liệu muốn khôi phục. Symantec Backup Exec sẽ cho phép bạn khôi phục mọi vùng lưu trữ thông tin như một vùng lưu trữ hay những hòm thư riêng biệt. Quá trình khôi phục những hòm thư riêng biệt không yêu cầu phải backup từng phần, đây là một tiến trình được tích hợp sẵn để khôi phục dữ liệu sử dụng công cụ này (hình 6). Công cụ Backup Exec 11d đủ khả năng để nhận ra sự có mặt của Recovery Storage Group, và nó sẽ không cố gắng khôi phục dữ liệu tới một vũng lưu trữ thông tin đang hoạt động.


Hình 6: Cửa sổ Restore Job Properties.
Khôi phục dữ liệu tới vùng lưu trữ thông tin đang hoạt động

Bạn có thể sử dụng Exchange System Manager hay ExMerge để di chuyển dữ liệu từ vùng lưu trữ hòm thư của Recovery Storage Group tới vùng lưu trữ thông tin đang hoạt động. Sử dụng Exchange System Manager dễ dàng hơn nhiều so với sử dụng ExMerge vì nó không yêu cầu bất kì giấy phép bổ sung nào để có thể sử dụng, và bạn sẽ không phải làm việc với các file .PST.

Tuy nhiên, Exchange System Manager tích hợp ít chức năng hơn so với ExMerge. ExMerge có thể cho phép bạn lọc những dữ liệu muốn khôi phục. Cho dù đang sử dụng công cụ nào thì trước tiên bạn vẫn phải đảm bảo rằng tài khoản người dùng sở hữu dữ liệu mà bạn đang khôi phục phải tồn tại trong Active Directory, nếu không bạn sẽ phải tạo lại nó trước khi tiếp tục.
Sử dụng Exchange System Manager

Trong Exchange System Manager, bạn hãy cài Exchange Recovery Storage Group vừa tạo và lưu trữ nó với các hòm thư. Thực hiện các thao tác sau:

1. Phải chuột lên vùng lưu trữ hòm thư, chọn Mount Store như trong hình 7.


Hình 7: Lựa chọn Mount Store để cài Recovery Group mới tạo.
2. Tiếp theo phải chuột lên vùng lưu trữ này một lần nữa rồi chọn Refresh để hiển thị danh sách các hòm thư trong bảng bên phải.



3. Phải chuột lên hòm thư muốn khôi phục rồi chọn Select Task (hình 8). Sau đó Exchange Task Wizard sẽ được khởi chạy như trong hình 9.


Hình 8: Lựa chọn hòm thư muốn khôi phục.

Hình 9: Exchange Task Wizard sẽ khôi phục dữ liệu hòm thư.
4. Trên trang Recover Mailbox Data bạn sẽ thấy hai tùy chọn bao gồm:
  • Merge Data: Cho phép trộn hòm thư được khôi phục với một hòm thư đang hoạt động và bỏ qua việc nhân bản email.
  • Copy Data: Tùy chọn này sẽ copy mọi dữ liệu trong hòm thư đang hoạt động rồi tạo ra các bản sao của các email (hình 10).


Hình 10: Lựa chọn tùy chọn Merge Data hoặc Copy Data trong Exchange Task Wizard.
5. Sau đó hoàn thành các bước còn lại trên Wizard này và xác nhận rằng mọi email đã nằm trong đúng hòm thư của nó.
Sử dụng ExMerge

Có thể bạn đã khá quen thuộc với ExMerge và các thao tác cấu hình cấp phép. Tốt nhất bạn nên sử dụng phiên bản ExMerge được tích hợp trong bản Service Pack của bản Exchange Server đang sử dụng. Nếu không một tiến trình nào đó có thể thất bại.

Khởi chạy ExMerge như bình thường, nhưng lưu ý rằng khi đó bạn sẽ thấy một màn hình hiển thị vùng lưu trữ hòm thư của Recovery Storage Group như những vùng lưu trữ hòm thư khác (hình 11).


Hình 11: ExMerge hiển thị những vùng lưu trữ hòm thư của Recovery Storage Group
và những vùng lưu trữ hòm thư thông thường.

Để khởi chạy ExMerge bạn cần thực hiện các thao tác sau:

1. Lựa chọn vùng lưu trữ của Recovery Storage Group rồi tiếp tục khôi phục dữ liệu sang một hoặc nhiều file .PST. Khi đã khôi phục dữ liệu sang file .PST, bạn có thể import file này vào hòm thư đang hoạt động sử dụng Microsoft Outlook.

2. Sau khi đã khôi phục dữ liệu, bạn có thể gỡ bỏ vùng lưu trữ hòm thư trong Recovery Grouplưu trữ dữ liệu này tại đó, hay sử dụng Exchange System Manager để xóa bỏ cả dữ liệu Recovery Storage Group.

Lưu ý: Để tiết kiệm dung lượng ổ cứng, bạn có thể xóa thủ công những file khôi phục được lưu trữ trong folder Recovery Storage Group của file hệ thống.

12 Mar 2010

Recovery Storage Group Restore with Backup Exec

Details:
The Recovery Storage Group (RSG) feature in Exchange 2003 allows you to mount a second copy of an Exchange mailbox store on any Exchange server in the same Exchange Administrative Group as the original, while the original store is still running and serving clients. This allows you to recover data from an older backup copy of the store without disturbing client access to current data. After the RSG is created and one or more stores are added to it, you can restore online backup sets to it. Then use the Exchange Server 2003 version of Microsoft Exchange Mailbox Merge Wizard (Exmerge.exe) to extract mailbox data from the stores into .PST files, and optionally merge the extracted data back into the online stores.
Note: Only Exchange mailbox stores from Exchange 2000 Service Pack 3 (SP3) or later can be restored to the RSG. Restored mailbox stores are upgraded to the store version currently running on the RSG server.

The following are requirements for restoring Microsoft Exchange 2003 data using the Recovery Storage Group (RSG):
  • Mailbox stores in the RSG must come from the same storage group. You cannot add mailbox stores from different storage groups to the RSG at the same time.
  • The mailbox store that you are adding to the RSG has to be located on the same server that you are restoring to if performing a redirected restore of a Mailbox Store from another server.
  • Public folder stores are not supported for restore using the RSG.
  • Do not mount mailbox stores in the RSG before the restore. If you do mount the stores before the restore, then you must dismount them and select "This database can be overwritten by a restore" on the database property page in Exchange System Manager prior to restoring them.
  • On the server that hosts the RSG, there must be a storage group with the same name as the original storage group for the data you are restoring. If no such storage group exists on the server, then you must create the storage group name as it existed originally during the backup and the mailbox store name that the RSG references must have the same name as the backed up version. (In 11.x and later versions, the RSG can exist on any server in the Forest and there does not have to be a regular SG with the name of the original SG present.)
  • The Active Directory topology of the Exchange system must be intact and in the same state it was in when the backup was made. You cannot restore mailbox stores that were deleted and recreated. In addition, you cannot recover mailboxes from stores if the mailboxes were deleted and purged from the system or moved to other servers or mailbox stores.
  • When the RSG exists on a server, the mailbox stores that it contains are the only stores that can be restored on that server by default. Symantec recommends that you create the RSG only when you intend to recover data using it, and remove the RSG from the server after the data recovery is complete.
· ·
Refer to your Microsoft Exchange Server 2003 documentation for more information on the requirements and restrictions of recovering Exchange data using the RSG or you may reference Microsoft Knowledge Base Article - 824126.

To create a Recovery Storage Group:

1. Start Exchange System Manager. Expand Administrative Groups (if appropriate), expand the Administrative Group Name (if appropriate), and then expand Servers
2. Right-click ServerName, point to New, and then click Recovery Storage Group.
3. In the Name box, type a name for the Recovery Storage Group. Try to use the same name that you used for the original storage group when you specify a name for the Recovery Storage Group. If you receive an error message that is similar to the following and Figure 1 when you do so, use a different name for the Recovery Storage Group:

The object StorageGroupName already exists.

Figure 1

4. Enter a unique directory name for this object. In the Transaction log location and in the System path location boxes, specify a location for the transaction log files and for the system path. Make sure that the location that you specify for the transaction log files for the Recovery Storage Group is different from the location that is specified for the transaction log for the original storage group. Click OK.

5. Right-click the Recovery Storage Group that you created, and then click Add Database to Recover (Figure 2)

Figure 2

6. In the Select database to recover dialog box, click the mailbox store that you want to add to the Recovery Storage Group, and then click OK. In the Mailbox Store Properties dialog box, review the properties of the mailbox store, and then click OK (Figure 3).

** Important ** Make sure that while reviewing the Mailbox store information, if you have multiple Exchange servers in your configuration, the name and location match the Mailbox store that you intended to attach to the RSG.

Figure 3

Do we need to mount storage??????????????????????????????????????????

To restore Exchange 2003 databases using the Recovery Storage Group:

1. On the navigation bar in Backup Exec, click Restore. On the Properties pane, under Source, click Selections. In the restore selections list, select the backup sets you want to restore (Figure 4).
Note: make sure you select the mailbox store only. Public Folder stores are not supported for restore using the RSG.

Figure 4

2. On the Properties pane, under Settings, click Exchange. Select the appropriate options.

Note: Do not select the Commit after restore completes checkbox and the Mount database after restore checkbox on the Restore Job Properties dialog box for Exchange unless your selections include the last backup set to be restored. These selections direct the Exchange server to replay transactions, roll back uncommitted transactions, and mount the databases after the restore.

3. If the RSG resides on a different Exchange server than the databases you are restoring, you can redirect the restore by selecting Exchange Redirection (Figure 5)

Figure 5

4. Start the restore job

5. When the restore is complete, use the EXMerge utility in Exchange 2003 to extract the mailbox data you need from the restored mailbox stores and optionally merge the data back into the online stores (Figure 6)

Figure 6

Total Pageviews