Quick Start Guide for IBM® Tivoli Storage Manager® · QUICK START GUIDE Quick Start Guide for...

QUICK START GUIDE

Quick Start Guide for IBM® Tivoli Storage Manager® Riverbed Technical Marketing

September 2012

Riverbed® Whitewater® Cloud Storage Gateway

RIVERBED WHITEWATER QUICK START GUIDE

© 2012 Riverbed Technology. All rights reserved. 1

© 2012 Riverbed Technology. All rights reserved. Riverbed®, Cloud Steelhead®, Granite™, Interceptor®, RiOS®, Steelhead®, Think Fast®, Virtual Steelhead®, Whitewater®,Mazu®, Cascade®, Cascade Pilot™, Shark®, AirPcap®, SkipWare®, TurboCap®, WinPcap®, Wireshark®, and Stingray™ are trademarks or registered trademarks of Riverbed Technology, Inc. in the United States and other countries. Riverbed and any Riverbed product or service name or logo used herein are trademarks of Riverbed Technology. All other trademarks used herein belong to their respective owners. The trademarks and logos displayed herein cannot be used without the prior written consent of Riverbed Technology or their respective owners. Akamai® and the Akamai wave logo are registered trademarks of Akamai Technologies, Inc. SureRoute is a service mark of Akamai. Google® is a registered trademark of Google and its affiliates in the United States and in other countries. Salesforce® is a registered trademark of Salesforce.com and its affiliates in the United States and in other countries. Apple and Mac are registered trademarks of Apple, Incorporated in the United States and in other countries. Cisco is a registered trademark of Cisco Systems, Inc. and its affiliates in the United States and in other countries. EMC, Symmetrix, and SRDF are registered trademarks of EMC Corporation and its affiliates in the United States and in other countries. IBM, iSeries, and AS/400 are registered trademarks of IBM Corporation and its affiliates in the United States and in other countries. Linux is a trademark of Linus Torvalds in the United States and in other countries. Microsoft, Windows, Vista, Outlook, Office 365, BPOS and Internet Explorer are trademarks or registered trademarks of Microsoft Corporation in the United States and in other countries. Oracle and JInitiator are trademarks or registered trademarks of Oracle Corporation in the United States and in other countries. UNIX is a registered trademark in the United States and in other countries, exclusively licensed through X/Open Company, Ltd. VMware, ESX, ESXi are trademarks or registered trademarks of VMware, Incorporated in the United States and in other countries. This documentation is furnished “AS IS” and is subject to change without notice and should not be construed as a commitment by Riverbed Technology. This documentation may not be copied, modified or distributed without the express authorization of Riverbed Techn ology and may be used only in connection with Riverbed products and services. Use, duplication, reproduction, release, modification, disclosure or transfer of this documentation is restricted in accordance with the Federal Acquisition Regulations as applied to civilian agencies and t he Defense Federal Acquisition Regulation Supplement as applied to military agencies. This documentation qualifies as “commercial computer software documentation” and any use by the government shall be governed solely by these terms. All other use is prohibited. Riverbed T echnology assumes no responsibility or liability for any errors or inaccuracies that may appear in this documentation.



Table of Contents Executive Summary .................................................................................................................................................................................................... 4

IBM Tivoli Storage Manager Architecture Overview ................................................................................................................................................... 4

Riverbed Whitewater Cloud Storage Gateway Overview ........................................................................................................................................... 5

Deploying Whitewater Gateways with IBM Tivoli Storage Manager ........................................................................................................................... 6

IBM Tivoli Storage Manager, Riverbed Whitewater Gateway, and Cloud Storage Configuration Example ............................................................... 6

Pre-deployment Checklist ........................................................................................................................................................................................... 6

Cloud Storage Provider Required Tasks .................................................................................................................................................................... 7 Amazon S3 ............................................................................................................................................................................................................ 7 AT&T Synaptic Storage as a Service .................................................................................................................................................................. 7 Nirvanix Cloud Storage Network ......................................................................................................................................................................... 7 EMC Atmos ............................................................................................................................................................................................................ 8 Microsoft Windows Azure .................................................................................................................................................................................... 8 Rackspace Cloud Files ......................................................................................................................................................................................... 8 OpenStack Object Storage (Swift) ...................................................................................................................................................................... 8

Configuring the Whitewater Gateway ......................................................................................................................................................................... 9 Configuring the Whitewater Management Interface.......................................................................................................................................... 9 Connecting to the Management Console GUI ................................................................................................................................................. 10 Configuring Whitewater Gateway Licenses ..................................................................................................................................................... 11 Configuring Whitewater Data Interfaces .......................................................................................................................................................... 11 Configuring Cloud Settings ............................................................................................................................................................................... 12 Configuring a CIFS Share .................................................................................................................................................................................. 13

Configuring IBM Tivoli Storage Manager .................................................................................................................................................................. 15 IBM Tivoli Storage Manager Management Console Overview ....................................................................................................................... 15 Adding a Whitewater Gateway to IBM Tivoli Storage Manager Tasks .......................................................................................................... 15 Create a FILE Device Class................................................................................................................................................................................ 16 Create a Primary or Copy Storage Pool ........................................................................................................................................................... 18 Associate Backups to the New Primary Storage Pool .................................................................................................................................... 20

Method 1: Associate a Policy Domain to the new Primary Storage Pool ................................................................................. 20 Method 2: Assign the New Storage Pool as the Next Storage Pool in the Hierarchy .............................................................. 22



Testing Tivoli Storage Manager with Whitewater ..................................................................................................................................................... 24 Method 1: Whitewater Used as a Primary Storage Pool ................................................................................................................................. 24 Method 2: Whitewater Used as the Next Primary Storage Pool in the Storage Pool Hierarchy ................................................................. 27 Method 3: Whitewater Used as a Copy Storage Pool ..................................................................................................................................... 28

Appendix A. Whitewater Best Practices for IBM Tivoli Storage Manager ................................................................................................................ 30 TSM Storage Pool Setup .................................................................................................................................................................................... 31

Appendix B. Whitewater Best Practices for Solaris Operating Systems .................................................................................................................. 32

Appendix C. Whitewater Best Practices for Windows 2008 Operating Systems ...................................................................................................... 32

Appendix D. Disaster Recovery (DR) Procedures .................................................................................................................................................... 33 Pre-Disaster Recovery Checklist ...................................................................................................................................................................... 33 Whitewater Gateway Recovery.......................................................................................................................................................................... 34 TSM Server Recovery ......................................................................................................................................................................................... 36 Production Systems Recovery .......................................................................................................................................................................... 38

Conclusion ................................................................................................................................................................................................................ 39

About Riverbed ......................................................................................................................................................................................................... 39



Executive Summary This paper outlines the ease of use and deployment of Riverbed® Whitewater® cloud storage gateway with IBM Tivoli Storage Manager (TSM). Whitewater gateways provides a simple, efficient way to offsite data to cloud storage providers powered by Amazon® S3, AT&T® Synaptic Storage as a Service, HP® Cloud Services, Microsoft® Windows® Azure cloud storage, Nirvanix® Cloud Storage Network, Rackspace® Cloud Files, and general instances of EMC® Atmos and OpenStack™ (Swift) Object Storage. Whitewater gateways simply acts as a storage unit within a backup infrastructure managed by IBM Tivoli Storage Manager, enabling organizations to eliminate their reliance on tape infrastructure and all of its associated capital and operational costs, while improving backup windows and disaster recovery capabilities. It is simple to set up the Whitewater gateway and start moving data to the cloud in a few hours, compared to setting up tape or other disk replication infrastructures which can take days. Leveraging Riverbed’s industry leading deduplication, compression and WAN optimization technologies, Whitewater gateways shrink data set sizes by 10 to 30x substantially reducing cloud storage costs, accelerating data transfers and storing more data within the local cache, speeding recovery. Security is provided by encrypting data on-site, in-flight, as well as in the cloud using 256-bit AES encryption and SSL v3. Whitewater gateway provides a dual layer of encryption that ensures that any data moved into the cloud is not compromised, and it creates a complete end-to-end security solution for cloud storage. Since a Whitewater appliance is an asymmetric, stateless gateway, no hardware is needed in the cloud and you can recover the last known good state of a broken or destroyed Whitewater gateway to a new Whitewater gateway. Whitewater gateways provide flexibility to scale cloud storage as the business requirements change. All capital expenditure planning required with tape and disk replication based solutions is avoided, saving organizations 30-50%.

IBM Tivoli Storage Manager Architecture Overview IBM Tivoli Storage Manager software provides a wide range of storage management capabilities from a single point of control, helping companies ride the information tidal wave. With its client/server design, Tivoli Storage Manager helps simplify the protection and management of your data, addresses business continuity by helping to shorten backup and recovery times and helps to maximize application availability with advanced data recovery management technologies. In IBM Tivoli Storage Manager all aspects of operations from backups to server management are conducted via the IBM Tivoli Storage Manager Administration Console. Administrators can run the Administration Console from any server in the network. See Diagram 1 for an image of a typical Tivoli Storage Manager deployment.



Diagram 1 Typical Tivoli Storage Manager Network View

Riverbed Whitewater Cloud Storage Gateway Overview

Figure 1 Whitewater gateway

The Riverbed Whitewater gateway is a disk-to-disk backup and archive storage gateway with unique cloud storage capabilities. Whitewater gateways easily integrate into your existing backup infrastructure and cloud storage. All of the standard backup applications allow you to add a Whitewater gateway as a common target within its existing infrastructure. The backup server connects to the Whitewater gateway using standard CIFS or NFS protocols. When you backup to a Whitewater device, it performs byte-level inline deduplication of the backup data to minimize storage consumption and transmission times. Whitewater gateways also use their local disk cache for local storage and recovery of recent backups, providing LAN performance for the most likely restores. The Whitewater gateway then writes the deduplicated backup data to cloud storage, and also accelerate restores from the cloud by moving only deduplicated data over the WAN. The gateway management console enables you to manage all of this through a web browser interface.



Deploying Whitewater Gateways with IBM Tivoli Storage Manager IBM Tivoli Storage Manager with Riverbed Whitewater disk-to-disk backup and archive gateway provide users with a flexible, easy-to-configure and use solution that can be deployed with major cloud storage providers. The sections below provide example configurations and setup steps needed to begin using Whitewater gateways. For further information about performance tuning IBM TSM with Whitewater appliances, please refer to the Whitewater Best Practices Guide for Backup Applications.

IBM Tivoli Storage Manager, Riverbed Whitewater Gateway, and Cloud Storage Configuration Example

Diagram 2 Logical Architecture View

Pre-deployment Checklist

1. Users will need a least one server that combines the function of an IBM Tivoli Storage Manager server and Administration Console into a single computer system. The operating system must be either Windows 2003 or Windows 2008. Memory requirements will vary, but at minimum an IBM Tivoli Storage Manager server should have 8GB of RAM or higher. Please check IBM’s support site and related compatibility lists where applicable. http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager_Extended_Edition 2. Obtain server systems and related software media supported by Windows 2003 or Windows 2008 R2, IBM Tivoli Storage Manager and Riverbed Whitewater gateway. 3. A Whitewater physical or virtual gateway needs to be online and connected to the physical network infrastructure. 4. You must procure and setup all necessary software licenses from each vendor, including Riverbed, using vendor-specific guidelines. 5. Physical stacking and racking of equipment at each site. All cabling and power must be operational. Verify that all LAN and WAN connections are functioning to and from Internet and cloud storage provider(s) 6. Set up the Windows server(s) within an existing or new created naming service such as Active Directory.

http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager_Extended_Edition



Cloud Storage Provider Required Tasks

Amazon S3

To sign up for Amazon S3:

1. Go to http://aws.amazon.com/s3 and click 2. Follow the on-screen instructions. 3. AWS will notify you by e-mail when your account is active and available for you to use. 4. Create a bucket: http://docs.amazonwebservices.com/AmazonS3/latest/gsg/CreatingABucket.html 5. Follow the link to continue with the process: http://docs.amazonwebservices.com/AmazonS3/latest/gsg 6. Make sure that you record the following information:

Access Key - Specify the access key (similar to the user name) for your Amazon S3 (AWS) account.

Secret Key - Specify the secret key (password) for your Amazon S3 provider account.

Bucket Name – Specify the bucket name created in step 4 above.

AT&T Synaptic Storage as a Service

To sign up for AT&T Synaptic Storage as a Service: 1. Go to the following website and click Sign Up Now: http://www.business.att.com/enterprise/Family/application-hosting-enterprise/storage-as-a-service-enterprise/ 2. Follow the on-screen instructions. 3. Receive the confirmation email and login to the AT&T Synaptic Storage as a Service website. 4. Record the following information:

Tenant ID - Specify the tenant ID that AT&T Synaptic Storage as a Service uses to authenticate each request.

UID - Specify the application ID (also known as UID) used to authenticate each request.

Shared Secret - Specify the shared secret that AT&T Synaptic Storage as a Service uses to authenticate each request.

Nirvanix Cloud Storage Network

To sign up for Nirvanix Cloud Storage Network:

1. Go to http://www.nirvanix.com/how-to-buy/index.aspx and click 2. Follow the on-screen instructions. 3. Receive the confirmation email and login to the Nirvanix Cloud Storage Network: https://nmp.nirvanix.com/default.aspx 4. Create an application name, and record the following information related to that application:

Application Key - Specify the application key established during account registration.

Application Name - Specify the application key established during account registration.

UserName - Specify the user account name established during account registration.

Password - Specify the password established during account registration. Note: Users can get the Application Name/Key by going to https://nmp.nirvanix.com/applications.aspx

http://aws.amazon.com/s3

http://docs.amazonwebservices.com/AmazonS3/latest/gsg/CreatingABucket.html

http://docs.amazonwebservices.com/AmazonS3/latest/gsg

http://www.business.att.com/enterprise/Family/application-hosting-enterprise/storage-as-a-service-enterprise/

http://www.nirvanix.com/how-to-buy/index.aspx

https://nmp.nirvanix.com/default.aspx

https://nmp.nirvanix.com/applications.aspx

http://aws.amazon.com/s3

http://www.business.att.com/enterprise/Family/application-hosting-enterprise/storage-as-a-service-enterprise/



EMC Atmos

Please refer to EMC Atmos documentation for information about preparing EMC Atmos for use with a Whitewater gateway. When ready, EMC Atmos will provide the following information for you to enter into the Whitewater GUI:

Host Name – Hostname or IP address of the EMC Atmos gateway.

Sub Tenant ID – Specify the tenant ID that is used to authenticate each request.

UID – Specify the user ID that is used to authenticate each request.

Shared Secret - Specify the shared secret used to authenticate each request.

Microsoft Windows Azure

To sign up for Microsoft Windows Azure:

1. Go to http://www.microsoft.com/windowsazure/free-trial/ and click 2. Follow the on-screen instructions. 3. Perform account confirmation via phone or text message. 4. Login to the Azure portal https://windows.azure.com/Default.aspx and create a new Storage Account under Hosted Services, Storage Accounts & CDN. 5. Record the following information from the created storage account to enter into the Whitewater GUI:

Storage Account – Provide the name of the storage account created in Azure.

Primary/Secondary Key – Provide either the primary or secondary access key from the storage account created.

Rackspace Cloud Files

To sign up for Rackspace Cloud Files:

1. Go to https://signup.rackspacecloud.com/signup and sign up for 2. Once account registration is complete, login to the Rackspace portal: US: https://manage.rackspacecloud.com/pages/Login.jsp UK: https://lon.manage.rackspacecloud.com/pages/Login.jsp 3. Access Your Account > API Access, and record the following information to enter into the Whitewater GUI:

Access Key – Provide the API key used to access the cloud account.

Username – Provide the user name associated with the account.

OpenStack Object Storage (Swift)

Please refer to OpenStack documentation (http://docs.openstack.org/) for information about deploying an OpenStack Object Storage cluster for use with Whitewater gateways. You should have the following information ready to enter into the Whitewater GUI:

Host Name – Hostname or IP address of the OpenStack Object Storage Proxy server

Port – Port on which the OpenStack Object Storage Proxy server listens to

Username – Specify the username that is used to authenticate each request.

Password – Specify the password that is used to authenticate each request.

http://www.microsoft.com/windowsazure/free-trial/

https://windows.azure.com/Default.aspx

https://signup.rackspacecloud.com/signup

https://manage.rackspacecloud.com/pages/Login.jsp

https://lon.manage.rackspacecloud.com/pages/Login.jsp

http://docs.openstack.org/



Configuring the Whitewater Gateway The Whitewater Installation Guide and Whitewater User’s Guide provide full details for requirements and installation of the Whitewater gateway. The configuration is broken down into the following activities:

Configuring the Whitewater Management Interface

Connecting to the Whitewater Management Console

Configuring Whitewater Gateway Licenses

Configuring Whitewater Data Interfaces

Configuring Cloud Settings

Configuring a CIFS Share

Configuring the Whitewater Management Interface

After you install and start the Whitewater appliance, connect to the Whitewater CLI to configure the management interface: 1. If you are using a virtual Whitewater gateway, connect directly to the console session using the VMware vSphere client and skip to step 3. If you are using a physical Whitewater gateway, plug the serial cable into the Console port and a terminal. 2. Start your terminal emulation program, such as Tera Term Pro. The terminal device must have the following settings: Baud rate: 9600 bps Data bits: 8 Parity: none Stop bits: 1 vt100 emulation No flow control Note: If you are using Whitewater with a terminal server, the terminal server must use hardware flow control for the port connected to Whitewater. 3. Log in as an administrator user (admin) and enter the default password (password): login as: admin password: password 4. The configuration wizard automatically starts after you have entered the login and default password. Enter yes at the system prompt to begin the configuration wizard. For example: Do you want to use the configuration wizard for initial configuration? yes 5. Complete the configuration wizard steps on the client side and server side:

Wizard Prompt Description Example

Step 1: Host name? Enter the host name for Whitewater. Step 1: Hostname? Amnesiac

Step 2: Use DHCP on the primary interface?

You are given the option to enable the DHCP to automatically assign an IP address to the primary interface for Whitewater. Riverbed recommends that you do not set DHCP. The default value is no.

Step 2: Use DHCP? no

Step 3: Primary IP address? Enter the IP address for Whitewater. Step 3: Primary IP address? 10.10.10.6

Step 4: Netmask? Enter the netmask address. Step 4: Netmask? 255.255.0.0

Step 5: Default gateway? Enter the default gateway for Whitewater. Step 5: Default gateway? 10.0.0.1

Step 6: Primary DNS server? Enter the primary DNS server IP address. You must specify the primary DNS server for cloud provider name resolution. If you do not specify a valid DNS server, the system will not start.

Step 6: Primary DNS server? 10.0.0.2

Step 7: Domain name? Enter the domain name for the network where Whitewater is to reside. If you set a domain name, you can enter host names in the system without the domain name.

Step 7: Domain name? example.com

Step 8: Admin password? Riverbed strongly recommends that you change the default administrator password (password) at this time. The new password must be a minimum of 6 characters.

Step 8: Admin password? xxxyyy

6. To log out of the system, enter the following command at the system prompt: amnesiac> exit



Connecting to the Management Console GUI

After you configure Whitewater, you can verify and modify your configuration settings and view performance reports and system logs in the Management Console. You can connect to the Management Console through any supported Web browser. To connect to the Management Console you must know the host, domain, and administrator password that you assigned in the configuration wizard. Note: Cookies and JavaScript must be enabled in your Web browser. To connect to the Management Console: 1. Enter the URL for the Management Console in the location box of your Web browser: protocol://host.domain – protocol is http or https. https uses the SSL protocol to ensure a secure environment. If you use https to connect, the system prompts you to inspect and verify the SSL key. – host is the host name you assigned to Whitewater during initial configuration. If your DNS server maps that IP address to a name, you can specify the DNS name. – domain is the full domain name for Whitewater. Note: You can specify the IP address instead of the host and domain. 2. The Management Console appears, displaying the login page as shown in Figure 2.

Figure 2 Riverbed Whitewater Management Console

-In the Username text box, type the user login: admin or monitor. The default login is admin. Users with administrator (admin) privileges can configure and administer Whitewater. Users with monitor (monitor) privileges can view connected Whitewaters, reports, and system logs. -In the Password text box, type the password that you assigned in the configuration wizard. By default the password is password. -Click Log In to display the Home page. The Home page summarizes the current status of your system.



Configuring Whitewater Gateway Licenses

You can add or remove a license in the Configure > Maintenance > Licenses page. You install a license on a Whitewater gateway after receiving it from Riverbed Technical Support or Sales. To add or remove a license: 1. Choose Configure > Maintenance > Licenses to display the Licenses page, as shown in Figure 3.

Figure 3 Whitewater Gateway Licenses Page

2. Complete the configuration as described in the following table.

Control Description

Add a New License Displays the controls (licenses text box) to add a new license.

Remove Selected Displays the controls to remove a license. Select the license you wish to delete and click Remove Selected to delete it.

Licenses Text Box Copy and paste the license key provided by Riverbed Technical Support or Sales into the text box. Tip: Separate multiple license keys with a space, Tab, or Enter.

Add Adds the license.

3. Click Save to save your settings permanently.

Configuring Whitewater Data Interfaces

You can view and modify settings for the data interfaces in the Configure > Networking > Data Interfaces page. To display and modify the configuration for data interfaces: 1. Choose Configure > Networking > Data Interfaces to display the Data Interfaces page, as shown in Figure 4.

Figure 4 Whitewater Data Interface Page



2. Under Data Network Interfaces, complete the configuration as described in the following table.

Control Description

Network Interface Displays the controls to add a network interface. Click the magnifying glass icon next to an interface to display the controls to configure the interface. Riverbed recommends that you use the network interfaces for backup and LAN traffic.

IP Configuration Displays the IP address of the network interface.

Enable Data Interface

Check this check box to enable the data interface and specify the following settings: • IPv4 Address - Specify an IP address. • IPv4 Subnet Mask - Specify a subnet mask. • Data Gateway IP - Specify the data gateway IP address. The data gateway must be in the same network as the data interface. • MTU - Specify the MTU value. The MTU is the largest physical packet size, measured in bytes, that a network can send. The default value is 1500.

3. Under Routing Table for <network interface> (for example, Routing Table for eth0_0), configure static routing in the routing table if your device management network requires static routes. You can add or remove routes as described in following table. Click Apply to apply your changes to the running configuration, and click Save to save your changes permanently.

Control Description

Add a New Route Displays the controls for adding a new route.

Destination Specify the destination IP address for the gateway.

Subnet Mask Specify the subnet mask.

Gateway Specify the IP address for the gateway. The gateway must be in the same network as the network interface you are configuring.

Add Adds the route to the table list.

Remove Selected Check the check box next to the name and click Remove Selected.

Configuring Cloud Settings

You can specify cloud settings, replication scheduling, and bandwidth limit settings in the Configure > Storage > Cloud Settings page. Replication is the process that transfers deduplicated data from Whitewater to the cloud asynchronously. A storage replication service provides an extra measure of redundancy that can be invaluable if the main storage backup system fails. Immediate access to the replicated data minimizes downtime and its associated costs. Replication streamlines disaster recovery processes by generating duplicate copies of all backed-up files on a continuous basis. It can also simplify recovery from all types of disasters including fire, flood, hurricane, virus, or worm. Note: Before you configure cloud settings, configure DNS settings to access the cloud service provider host machine. To configure cloud settings: 1. Choose Configure > Storage > Cloud Settings to display the Cloud Settings page, as shown in Figure 5.

Figure 5 Cloud Settings Page



2. Under Cloud Settings, complete the configuration as described in the following table.

Control Description

Protocol Type

Select the cloud service provider from the drop-down menu. If you select Amazon S3, you must also specify the following: • Access Key - Specify the access key (similar to the user name) for your Amazon S3 (AWS) account. • Secret Key - Specify the secret key (password) for your cloud service provider account. If you select AT&T Synaptic Storage, you must specify the following: • Sub Tenant ID - Specify the sub tenant ID that AT&T Synaptic Storage uses to authenticate each request. • UID - Specify the user ID that AT&T Synaptic Storage uses to authenticate each request. • Shared Secret - Specify the shared secret that AT&T Synaptic Storage uses to authenticate each request. When the client application builds a Web service request, AT&T Synaptic Storage uses the shared secret to create a signature entry as a part of the request. The shared secret must be associated with the tenant ID and application ID created by AT&T Synaptic Storage. If you select Nirvanix Storage, you must specify the following: • Application Key - Specify the application (access) key for your Nirvanix Storage account. • Application Name - Specify the application name of your Nirvanix Storage account. • Username - Specify the user name that Nirvanix Storage uses to authenticate each request. • Password - Specify the password that Nirvanix Storage uses to authenticate each request. If you select EMC Atmos, you must specify the following: • Sub Tenant ID - Specify the subtenant ID that EMC Atmos uses to authenticate each request. • UID - Specify the user ID that EMC Atmos uses to authenticate each request. • Shared Secret - Specify the shared secret that EMC Atmos uses to authenticate each request. When the client application builds a Web service request, EMC Atmos uses the shared secret to create a signature entry as a part of the request. The shared secret must be associated with the subtenant ID and application ID created by the EMC Atmos-based storage provider. If you select Microsoft Windows Azure, you must specify the following: • Storage Account – Provide the name of the storage account created in Azure. • Primary/Secondary Key – Provide either the primary or secondary access key from the storage account created. If you select Rackspace Cloud Files, you must specify the following: • Access Key - Specify the access key for the Rackspace account. • Username - Specify the user name associated with the Rackspace account. If you select OpenStack Object Storage, you must specify the following: • Password - Specify the password that OpenStack uses to authenticate each request. • Username - Specify the user name that OpenStack uses to authenticate each request.

Hostname Specify the hostname of the cloud provider on which Whitewater stores the replicated data. For example, s3.amazonaws.com or storage.synaptic.att.com.

Port Specify the port through which replication occurs. Amazon uses port 80, which is an unsecured port, or port 443, which is a secure port. AT&T Synaptic Storage, Nirvanix Storage, and EMC Atmos use port 443. The default value is 443, which works for all cloud providers.

Bucket Name Specify the bucket name associated with your cloud service provider account. Buckets are containers (similar to folders) that store deduplicated data sent from Whitewater.

Configuring a CIFS Share

You can configure Common Internet File System (CIFS) access to Whitewater in the Configure > Storage > CIFS page. CIFS is a protocol that allows programs to make requests for files and services on remote computers on the Internet. The share you configured appears in the list of shares on the page. When you add a CIFS share to Whitewater, you can enable authentication or leave it disabled (allowing all users to access the CIFS share). If you enable authentication, you must add CIFS users who can access the share. To configure CIFS: 1. Choose Configure > Storage > CIFS to display the CIFS page, as shown in Figure 6.

Figure 6 Adding a CIFS Share



2. To add a CIFS share, complete the configuration as described in the following table.

Control Description

Add CIFS Share Displays the controls to add a new CIFS share.

Share Name Specify the name of the share to be added.

Path Specify the pathname to the share to be added. It starts with a forward slash (/).

Comment Specify a comment about the share. You can only use alphanumeric, underscore (_), hyphen (-) characters and space in this field.

Read Only Check this check box if you want the share to be a read-only share.

Allow Everyone Access Check this check box to enable all clients connected to the Whitewater system to access the CIFS share.

Remove Selected Deletes the selected CIFS share.

Add Share Adds the CIFS share to the Whitewater CIFS server. The share you add appears in the list of shares on the page.

3. To add a CIFS user, complete the configuration as described in the following table.

Control Description

Add CIFS User Displays the controls to add a user to the Whitewater CIFS server.

User Name Specify the user name of a user to access the CIFS shares.

Password Specify the password to authenticate the user.

Password Confirm Specify the password again to confirm authentication.

Remove Selected Deletes the selected user name from the CIFS server.

Add Adds the user name and password to the Whitewater CIFS server.

4. To add Whitewater to an Active Directory (AD) domain, complete the configuration as described in the following table.

Control Description

Join Domain Displays the controls to add Whitewater to your AD domain.

Domain Name Specify the domain name of the AD that Whitewater must join. If your system has an AD domain, then you can add Whitewater to your AD domain and create share permissions for AD users and groups.

User Name Specify the user name of a user to access the AD domain. The user name must be a part of theAD and the user must have permissions to add computers to the domain.

Password Specify the password to authenticate the user.

DNS Domain Optionally, specify the DNS name of the domain.

Organization Unit Optionally, specify the organization unit within the domain to which Whitewater must join.

Hostname Optionally, specify the hostname that Whitewater must use to join the domain. Whitewater then appears as the specified hostname in the AD.

5. Under Global CIFS Settings, specify the values for SMB (Server Message Block) Signing and Guest Account. This setting overrides the setting under Add CIFS User. Select one of the following values for SMB Signing:

Disabled - The CIFS server does not offer SMB signing. This is the default value.

Auto - Enables SMB signing automatically. The CIFS server offers SMB signing, but does not enforce it. You can choose to enable or disable it.

Mandatory - The CIFS server enforces SMB signing. You must use SMB signing if you select this option. Select one of the following values for Guest Account:

Enabled - Activates the guest account. A user may authenticate as a guest user and access a CIFS share (which allows guest users) using any user name and password. If you want to enable any user to access the share, you can use this feature.

Disabled - De-activates the guest account. Note: Windows provides the ability to sign CIFS messages to prevent man-in-the-middle attacks when sharing files. Each CIFS message has a unique signature, which prevents the message from being tampered with. Note: Enabling SMB signing degrades Whitewater performance.



Configuring IBM Tivoli Storage Manager The following sections describe how to configure and use Tivoli Storage Manager with the Whitewater gateway - please refer to the IBM Tivoli Storage Manager Administrator’s Guide for complete details:

IBM Tivoli Storage Manager Administration Console Overview

Adding the Whitewater gateway to IBM Tivoli Storage Manager Tasks o Create a FILE device class o Create a primary or copy storage pool o Associate backups to the new primary storage pool

Method 1: Associate a policy domain to the new primary storage pool Method 2: Assign the new storage pool as the next storage pool in the hierarchy

Testing Tivoli Storage Manager with the Whitewater gateway o Method 1: Whitewater used as a primary storage pool o Method 2: Whitewater used as the next primary storage pool in the storage pool hierarchy o Method 3: Whitewater used as a copy storage pool

IBM Tivoli Storage Manager Management Console Overview

The Tivoli Storage Manager Administration Console is the interface that is used to configure all settings in a Tivoli Storage Manager server environment. In order for the Tivoli Storage Manager Administration Console to make changes the administration console must point to the desired Tivoli Storage Manager server. By default the administration console will locate the Tivoli Storage Manager server on the local system if present. The administration console can also be pointed at other Tivoli Storage Manager servers in environment to monitor activities and statistics for those particular Tivoli Storage Manager servers. To point the administration console to additional Tivoli Storage Manager servers, use the Manage Servers panel, as shown in Figure 7.

Figure 7 Tivoli Storage Manager Administration Console

Adding a Whitewater Gateway to IBM Tivoli Storage Manager Tasks

When adding a Whitewater gateway to a Tivoli Storage Manager environment there are three primary tasks that are required. The first is to create a FILE device class, which is associated with a CIFS share created on the Whitewater gateway. The second is to create a storage pool using that FILE device class so data volumes can be written to Whitewater based storage. Lastly, the policy domain must be modified so client backups are directed to use the new storage pool target.

Create a FILE device class (required)

Create a primary or copy storage pool (required)

Associate a policy domain to the new storage pool (required)

http://publib.boulder.ibm.com/infocenter/tsminfo/v6r2/topic/com.ibm.itsm.nav.doc/r_pdf_srv.html



Create a FILE Device Class

A FILE device class is a device descriptor which specifies the device type and media management information, such as the recording format, estimated capacity, and labeling prefixes. Tivoli Storage Manager associates device classes with physical storage. The following describes the steps to create a FILE device class and associate it to the Whitewater gateway. These steps use the best practice configuration for Tivoli Storage Manager with the Whitewater gateway. 1. Use the Storage Devices panel and select the radio button for the Tivoli Storage Manager server you wish to work with. Then click on the Select Action drop down menu and select View Device Classes, as shown in Figure 8.

Figure 8 View Device Classes Drop Down

2. When the Device Classes panel appears, click the Select Action drop down menu and select Create A Device Class, as shown in Figure 9.

Figure 9 Create a Device Class Drop Down



3. When the Create a Device Class wizard starts, click the Select a Device Type drop down menu and click on FILE (uses sequential-access volumes on disk), as shown in Figure 10. Click on Next to continue.

Figure 10 Selecting a Device Type Drop Down

4. Provide a new device class name, Whitewater CIFS share path name, and set the mount limit and maximum size values, as shown in Figure 11. Click on Next to continue.

Figure 11 Create a Device Class Configuration Screen

Name

Provide a new device class name. It cannot match an existing device class name. Path to Store Files

Enter a fully qualified domain name CIFS share path value which corresponds to the Whitewater CIFS share. Mount Limit

Recommend setting an initial value of 5 or less. This option controls the number of volumes that can be mounted simultaneously on a Tivoli Storage Manager server.

Maximum File Size

Recommend setting a value of 20GB or less. This option controls the maximum device file object size that can be created on Whitewater by Tivoli Storage Manager.



Create a Primary or Copy Storage Pool

A Tivoli Storage Manager storage pool is a collection of volumes that are associated with one device class and one media type. Storage pools can have volumes that are predefined or volumes that are created from a scratch pool of volumes. Scratch volumes are created by Tivoli Storage Manager. Backup data is written by a Tivoli Storage Manager client to a storage pool target. 1. Use the Storage Devices panel and select the radio button for the Tivoli Storage Manager server you wish to work with. Then click on the Select Action drop down menu and select View Storage Pools, as shown in Figure 12.

Figure 12 View Storage Pools Drop Down 2. When the Stoage Pools panel appears, click the Select Action drop down menu and select Create A Storage Pool, as shown in Figure 13.

Figure 13 Create a Storage Pool Drop Down



3. When the Create a Stoage Pool wizard starts, provide a new Storage Pool Name, select the Sequential Access radio button, and select whether the storage pool will be use in a primary or copy capacity, as shown in Figure 14. Click on Next to continue.

Figure 14 Storage Pool Name and Type Entry

Storage Pool Name

Provide a new storage pool name. It cannot match an existing storage pool name. Storage Pool Type

Select sequential access since Whitewater uses a FILE device class. Primary or Copy Storage Pool

Identifies whether the storage pool will be used for primary backups of data from Tivoli Storage Manager clients, or used for receiving copies of backup data stored in primary storage pools via the BACKUP STGPOOL command.

4. Click on the Device Class Name drop down and select the device class name created previously in Step 1. Also enter a value for the maximum number of scratch volumes, as shown below in Figure 15. Click Next to continue.

Figure 15 Device Class Name Selection and Maximum Volume Entry

Device Class Name

Provide the device class name created in Step1 above. Maximum Number of Scratch Volumes

This option controls the maximum number of scratch volumes that Tivoli Storage Manager will be allowed to create using the target device class media properties. This value can be set to whatever value you need, but should represent the total size of the Whitewater cache storage when multiplied by the per volume size specified in the Device Class creation step above.



Associate Backups to the New Primary Storage Pool

Once the storage pool is created, TSM must be configured to send data to the storage pool. In method 1, a policy domain can be updated to send data to that storage pool. In method 2, an existing storage pool can be associated to send data to the Whitewater storage pool as the next pool in the storage hierarchy. NOTE: Perform the following ONLY if you create a primary storage pool in step 2 above. If you create a copy storage pool, then skip this section. Method 1: Associate a Policy Domain to the new Primary Storage Pool

A policy domain describes how storage and management of backup data within a Tivoli Storage Manager server is performed. Policies are rules that you set at the Tivoli Storage Manager server to help you manage the client data lifecycle. Policies control how and when client data is stored, and where that data resides within the TSM storage devices. Note: It is not generally recommended to set the Whitewater gateway as the direct destination for TSM backup policies, due to the sequentially designed nature of Whitewater appliances, and the additional network requirements to perform backups to TSM and data movement to Whitewater simultaneously. 1. Use the Policy Domains panel and select the radio button for the Tivoli Storage Manager server you wish to work with. Then click on the Select Action drop down menu and select View Policy Domains, as shown in Figure 16.

Figure 16 View Policy Domains Drop Down

2. Select the radio button for the policy domain you wish to work with. Then click on the Select Action drop down menu and select Modify Policy Domain, as shown in Figure 17.

Figure 17 Modify Policy Domain Drop Down



3. Expand the Management Classes twistie, then click the check box of the management name you wish to edit. Then click on the Select Action drop down menu and select Modify Management Class, as shown in Figure 18.

Figure 18 Select the Management Class for Modification

4. In the management class properties panel that appears click on Backup Settings and select the storage pool created previously from the Where to Store Files drop down, as shown in Figure 19. Click OK to continue.

Figure 19 Modify the Storage Pool Target for Backups

5. After returning to the Policy Domain panel, you will need to activate the policy change. Click the Select Action drop down and select Manage Pending Changes, as shown in Figure 20.

Figure 20 Manage Pending Changes Drop Down



6. At the Manage Pending Changes panel, click the Activate Changes button to initiate the change for all future backups that are associated with this policy, as shown in Figure 21. Click OK.

Figure 21 Activate Changes for Policy Domain

Method 2: Assign the New Storage Pool as the Next Storage Pool in the Hierarchy

Storage pools can be setup in a hierarchy, such that data flows from one storage pool to another at regulated schedules or in the event of data overflow. Using a Whitewater gateway in this fashion will reduce the amount of simultaneous traffic on the network as opposed to method 1, since data flow to the Whitewater storage pool will be separate from backup data flow into the TSM server. 1. Use the Storage Devices panel and select the radio button for the Tivoli Storage Manager server you wish to work with. Then click on the Select Action drop down menu and select View Storage Pools, as shown in Figure 22.

Figure 22 View Storage Pools Drop Down



2. Select the radio button for the storage pool that will send data to the Whitewater storage pool, and from the drop down menu select Modify a Storage Pool, as shown in Figure 23.

Figure 23 Modify Storage Pool Drop Down

3. When the Storage Pool Properties window appears, select the Next Storage Pool dropdown, select the storage pool created in step 2 above and click Apply, as shown in Figure 24.

Figure 24 Next Storage Pool Selection



Testing Tivoli Storage Manager with Whitewater

Method 1: Whitewater Used as a Primary Storage Pool

Note: This test applies only if you configured Whitewater as a primary storage pool for backups from a policy domain. If you configured Whitewater as the next primary storage pool in a storage pool hierarchy, go to Method 2 below. If you configured Whitewater as a copy storage pool, go to Method 3 below. Note: It is not generally recommended to set the Whitewater gateway as the direct destination for TSM backup policies, due to the sequentially designed nature of Whitewater appliances, and the additional network requirements to perform backups to TSM and data movement to Whitewater simultaneously. 1. To test Tivoli Storage Manager with the Whitewater gateway you can run a manual backup. Start the Tivoli Storage Manager Backup-Archive GUI, and when the window appears click on Backup. In the Backup window that appears select the local drives or files to backup, and click Backup to begin the operation (Figure 25).

Figure 25 Initiating a Manual Backup

2. Backup activity will be provided in the Task List window, as shown in Figure 26. By clicking the Report button you can view detailed status of the operation, including throughput metrics and object counts (Figure 27).

Figure 26 Task List Status



Figure 27 Backup Detailed Status Report

3. When the backup is complete, perform a restore to validate that Whitewater can restore the backed up data. From the Tivoli Storage Manager Backup-Archive GUI, click on Restore. In the Restore window that appears select the local drives or files to restore, and click Restore to begin the operation (Figure 28).

Figure 28 Initiating a Restore



4. Restore activity will be provided in the Task List window, as shown in Figure 29. By clicking the Report button you can view detailed status of the operation, including throughput metrics and object counts (Figure 30).

Figure 29 Task List Status

Figure 30 Restore Detailed Status Report



Method 2: Whitewater Used as the Next Primary Storage Pool in the Storage Pool Hierarchy

Note: This test applies only if you configured the Whitewater appliance as the next primary storage pool in a storage pool hierarchy. If you configured Whitewater as a copy storage pool, go to Method 3 below. To move data to the Whitewater storage pool, update the migration thresholds for the storage pool that points to the Whitewater storage pool. This will trigger a migration process which will migrate data from the storage pool to the Whitewater appliance. 1. Use the Storage Devices panel and select the radio button for the Tivoli Storage Manager server you wish to work with. Then click on the Select Action drop down menu and select View Storage Pools, as shown in Figure 31Figure 32.


2. Select the storage pool from the list. When the properties page for the storage pool appears (Figure 32), click on the Migration tab. In the right pane, adjust the migration thresholds to lower values such that a migration process is triggered by TSM.

Figure 32 Migration Threshold Adjustment View



Method 3: Whitewater Used as a Copy Storage Pool

Note: This test applies only if you configured Whitewater as a copy storage pool. If you configured Whitewater as a primary storage pool, go to Method 1 or Method 2 above. To test Tivoli Storage Manager with the Whitewater gateway perform a copy storage pool backup. Start the Tivoli Storage Manager Administration Console, and expand Tivoli Storage Manager in the left tree. Click on Storage Devices. In the Storage Devices panel and select the radio button for the Tivoli Storage Manager server you wish to work with. Then click on the Select Action drop down menu and select View Storage Pools, as shown in Figure 33.


When the Stoage Pools panel appears, click the radio button next to the primray storage pool you wish to backup. Then click on the Select Action drop down menu and select Back Up Storage Pool, as shown in Figure 34.

Figure 34 Backup Up Storage Pool Action



Select the copy storage pool from the Copy storage pool drop down as shown in Figure 35. Click on OK to begin the backup storage pool process.

Figure 35 Copy Storage Pool Selection



Appendix A. Whitewater Best Practices for IBM Tivoli Storage Manager IBM Tivoli Storage Manager uses Device Classes and Storage Pools to store backup data from client systems. Tivoli Storage Manager Device Classes and Storage Pools can be viewed and modified from the Storage Devices Panel of the Tivoli Storage Manager Administration Console.

Figure 36 TSM Device Class Properties

Tivoli Storage Manager uses Whitewater CIFS shares as a FILE device class. Each FILE device class can point to one or more Whitewater CIFS share(s) via the directory option. It is recommended that each share path be comprised of a unique Whitewater hostname and share name value. Do not use Whitewater CIFS shares as a DISK device class.

Mount Limit should not be set to an initial value higher than 5 per Whitewater based FILE device class.

Maximum Volume Capacity should not be set to a value greater than 20GB (20480 MB).

Figure 37 TSM Storage Pool Properties

Reclamation Threshold should be set to a value of no lower than 80. Reclaiming volumes which have lower than 80% reclaimable space can cause unnecessary disk read and write activity.



Maximum number of scratch volumes can be set to any value allowed by Tivoli Storage Manager. If you wish to limit

the total amount of data stored to the cloud by Tivoli Storage Manager, set a maximum scratch volume limit which will accomplish this size requirement. For example, if you wish to only use a maximum of 40TB of space in the cloud and maximum volume capacity is set to 20GB, then the maximum number of scratch volumes value should be set to 40,000GB / 20GB = 2,000.

Number of days before an empty volume is reused should be set to 0 (default). This will immediately allow a volume to be reused for holding new backup data.

Figure 38 TSM Storage Pool Identify Duplicates

When creating a Whitewater based storage pool, leave the Identify the duplicate data in this storage pool checkbox unchecked as shown in Figure 5, and click Next and Finish to complete the wizard.

TSM Storage Pool Setup

There are 3 ways to setup Whitewater appliances with TSM: 1. Setup the Whitewater appliance as a primary sequential storage pool behind the existing disk storage pool. TSM uses the existing disk storage pool for fast writes for backups, and then migrates the data during the day to the Whitewater appliance. This method separates the network requirements of backups from the migration operations that move data to the Whitewater appliance. The Whitewater appliance can also serve as an offsite copy backup, but without having to implement a TSM copy storage pool configuration, saving time and resources on the TSM server. 2. Setup the Whitewater appliance as a copy storage pool. Similar to method 1, there will be no contention for network resources between backups and the copy storage pool operations to the Whitewater appliance, but in this setup the Whitewater serves only as the offsite copy. TSM Administrators will still need to configure a local onsite storage pool behind their primary disk pool. 3. Setup the Whitewater appliance as the primary disk storage pool. This is not recommended for most scenarios as the Whitewater appliance will likely be unable to keep up with the write requirements for many simulatenous backup streams, and the TSM server network resources will be in contention for both inbound backup and outbound Whitewater appliance activity. It is possible to configure the Whitewater gateway to be the primary and copy storage pool target (for example, if combining methods 1 and 2 above), but note that this will require additional network and cloud resources to perform, as well as reduce the amount of usable cache space since the Whitewater cache will have to make multiple references for each type of operation.



Appendix B. Whitewater Best Practices for Solaris Operating Systems NFS networking parameters on Solaris operating systems should be configured to optimally send data to Whitewater via configured NFS mounts. In addition to tuning the rsize and wsize mount options appropriately, nfs3_max_transfer_size and nfs3_bsize should also be tuned. nfs3_max_transfer_size and nfs3_bsize should be greater than or equal to minimum of rsize and wsize. To set the values, edit the /etc/system file and change/add the following lines to the file: nfs:nfs3_max_transfer_size=<value>

nfs:nfs3_bsize=<value>

A reboot of the system is required in order for the configuration changes to take effect.

Appendix C. Whitewater Best Practices for Windows 2008 Operating Systems Windows networking parameters for CIFS can be modified to improve overall backup application performance. To make these changes, go to Start Menu and enter regedit to start the Windows registry editor. Provide administrative permissions if prompted. Note that changes made within Windows registry editor are permanent upon entry so use extreme caution when making the changes/additions. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parame

ters]

"SESSTIMEOUT"=dword:00000e10

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters]

"DefaultSendWindow"=dword:00040000

"DefaultReceiveWindow"=dword:00040000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

"GlobalMaxTcpWindowSize"=dword:00040000

"TcpWindowSize"=dword:00040000

"Tcp1323Opts"=dword:00000003



Appendix D. Disaster Recovery (DR) Procedures Disaster recovery is the process of recovering the technology infrastructure after a natural or man-made disaster.

Diagram 3 Disaster Recovery - Functional Architecture View

For example, consider a TSM DR scenario with Riverbed Whitewater where the entire Production Site, including the Whitewater and the TSM server, are lost. However, at least one or more backups of that production environment exist in the cloud storage. To recover the data at the DR Site you need a new TSM server and a new physical or virtual Whitewater gateway (Diagram 3). Note: You do not need a Whitewater license to restore the data. Moreover, the virtual Whitewater appliance can be downloaded from the Riverbed Support site at https://support.riverbed.com.

Pre-Disaster Recovery Checklist

1. Export the current Whitewater Configuration and Encryption Key. Browse to the menu Configure -> Setup Wizard (Figure 39) and select Export Configuration to export the configuration

file. By default the naming of the file will be whitewater_config_(HOSTNAME)_(DATETIME).tgz.

Figure 39 Setup Wizard to Export Configuration and Encryption Key

Note: Riverbed recommends that you store the exported configuration file in different physical locations. You should also keep the configuration file within the DR Site.

https://support.riverbed.com/



2. If using the Whitewater appliance as a copy storage pool target, prepare the TSM server environment with TSM Disaster Recovery Manager (DRM).

Issue the following TSM server commands to set up DRM to manage Whitewater copy storage pool volumes: o SET DRMCOPYSTGPOOL <whitewater-copy-storagepool-name> o SET DRMFILEPROCESS YES o QUERY DRMEDIA COPYSTGPOOL=<whitewater-copy-storagepool-name>

Manage the DRM volumes and place them offsite as you would any typical DRM volumes using the MOVE DRMEDIA command.

Whitewater Gateway Recovery

The first step to recover from a catastrophic failure of your Production Site is to install and configure for disaster recovery a new physical or virtual Whitewater gateway. It is recommended to use a virtual Whitewater gateway for the initial recovery, which can be downloaded from the support website and quickly deployed within a VMware environment at the DR Site. While not required, the Whitewater at the DR Site is suggested to have the same or greater local storage capacity as the original Whitewater at the lost Production Site, should you decide to make these resources at the DR Site your production resources after the DR is complete. The following describes the steps to fully recover and restore the backup data from the cloud to the new physical or virtual Whitewater gateway. 1. Configure Whitewater to the new network environment at the DR site.

Plug a serial cable into the Console port and a terminal, or in the case of virtual Whitewater use the virtual VMware console.

Log in to Whitewater using the default login admin and default password password. Configure the Whitewater network information (Figure 40). For details, see the Whitewater Installation Guide.

Figure 40 Whitewater Configuration Wizard



2. Recover the original configuration of Whitewater to the new Whitewater at the DR site. Browse to the menu Configure -> Setup Wizard (Figure 41) and import the previously saved configuration file. Make

sure you leave the default “Import Shared Data Only” checkbox selected.

Figure 41 Setup Wizard to Import Configuration

3. Configure Whitewater Data Interfaces to the new network environment at the DR site.

Browse to the menu Configure -> Networking -> Data Interfaces (Figure 42) and configure Data Interfaces network information.

Figure 42 Data Interfaces Configuration Menu

4. Once the configuration is complete, connect to the Whitewater CLI using SSH and initiate the Replication Recovery procedure. For details, see the Riverbed Command-Line Interface Reference Manual. Issue the following commands:

whitewater > enable

whitewater # configure terminal

whitewater (config) # no service enable

whitewater (config) # replication recovery enable

whitewater (config) # service restart

Note that the replication recovery enable command will fail to execute if the optimization service is enabled, or if Whitewater detects existing data in the new Whitewater cache. Assuming this is a new, empty Whitewater gateway, you will not receive any failures and the commands will all be executed without error. This process can take a few seconds to a few hours depending on the backup(s) being restored. During the recovery process, the system communicates with the cloud provider and recovers all the namespace files that existed before the failure. 5. (Optional) Because the recovery process downloads only the namespace and metadata, initial file access might be slow, because Whitewater downloads all of the data from the cloud. Therefore, it is recommended that you also populate the actual data from the cloud back onto the new Whitewater in order to accelerate the recovery of your production systems. To do so, enter the following:

whitewater (config) # datastore prepop {[num-days <number of days>] | [pattern <pattern>] |

[recursive]}



Where the parameters are provided as shown in the following Table 1

Parameter Description

num-days <number of days> Filters the data retrieved by number of last-modified days.

pattern <pattern> Filters the data retrieved by the pattern you specify. Recursive Enables the data to be prepopulated in subdirectories under a

given

directory.

Table 1 Datastore Prepop Command Parameters

Refer to the Whitewater Users Guide for further details on this command. Note: If the Whitewater gateway storage capacity is less than the space used in the cloud, you can still initiate the recovery process. However, in this case the Whitewater gateway will only recover as much actual data as the size of its storage. If the recovery process attempts to bring back more data than the disaster recovery Whitewater can handle, then the recovery process might fail. Virtual Whitewater for example can store up to 2 TB of cloud data. For more details on Whitewater gateway sizes, see the Whitewater Installation Guide. At this point the Whitewater Recovery procedure is complete, now you need to recover the TSM server.

TSM Server Recovery

After the Whitewater gateway has been recovered you need to install and configure the TSM server. The below procedures assume that you are using TSM Disaster Recovery Manager (DRM), and have taken appropriate TSM server database backups. Refer to the TSM Disaster Recovery redbook available at redbooks.ibm.com for further details. 1. Install TSM server to a new host system at the DR site. Make sure that the installation and configuration of the TSM server db, log, and disk volumes is the same as in the previous production site, and that the DRM files are split up in preparation for disaster recovery. Several of the DRM files can help you identify the paths for each of the above items. 2. Edit the DRM file DEVICE.CONFIGURATION.FILE using a text editor and adjust the Whitewater device class name to reflect the new IP addressing of the Whitewater interfaces available at the DR site, as shown in Figure 43.

Figure 43 Device Configuration File

3. If the Whitewater appliance at the production site was used as a primary storage pool with TSM, edit the DRM file PRIMARY.VOLUMES.DESTROYED.MAC (Figure 44) and remove lines that refer to the Whitewater based volumes. Since the Whitewater appliance at the DR site will have recovered the data from the cloud provider, there will be no destroyed volumes that DRM will have to report to TSM, and they will be available when TSM is brought up.



Figure 44 Primary Volumes Destroyed File

4. If the Whitewater appliance at the production site was used as a copy storage pool with TSM, edit the DRM file COPYSTGPOOL.VOLUMES.AVAILABLE.MAC and adjust the Whitewater copy storage pool volume directory path to reflect the new IP addressing of the Whitewater interfaces available at the DR site. Since the Whitewater appliance at the DR site will have recovered the data from the cloud provider, there will be no destroyed volumes that DRM will have to report to TSM, and they will be available when TSM is brought up. 5. Run the DRM executable command file RECOVERY.SCRIPT.DISASTER.RECOVERY.MODE.CMD (Figure 45) to begin the process of restoring the TSM server to the last database backup state.

Figure 45 TSM Server Recovery Script



6. When the restore procedure is complete, start the TSM server. Login to the TSM management console interface, and use the Storage Devices panel and select the radio button for the Tivoli Storage Manager server you wish to work with. Then click on the Select Action drop down menu and select View Device Classes, as shown in Figure 46Figure 8.

Figure 46 View Device Classes Drop Down

7. When the device classes list appears, click on the device class name that corresponds to the Whitewater device class. The properties window will appear, and here you will edit the device class directory path to reflect the new network configuration of Whitewater at the DR site (Figure 47). Click OK to apply the changes.

Figure 47 Device Class Properties View

Production Systems Recovery

From this point forward, Whitewater and TSM are now configured as they were prior to the disaster, and you can now begin system restores of any production systems that need to be recovered at the DR site using normal TSM recovery strategies. Please refer to TSM documentation for recovering additional systems.



Conclusion Riverbed is extending its industry-proven deduplication to cloud storage. Riverbed deduplication make replication more efficient than in the past by reducing the amount of data that is transferred. Now, the Whitewater gateway will extend those industry-leading deduplication capabilities to cloud storage, cutting the cost of data backup and disaster recovery by significantly reducing the capital and operational costs of storage consumed as well as the bandwidth requirements for moving backup data into and out of the cloud. Backup policies can easily be reconfigured to take advantage of Riverbeds core technology strengths, resulting in improved backup and recovery benefits and increasing availability of data to users.

About Riverbed Riverbed delivers performance for the globally connected enterprise. With Riverbed, enterprises can successfully and intelligently implement strategic initiatives such as virtualization, consolidation, cloud computing, and disaster recovery without fear of compromising performance. By giving enterprises the platform they need to understand, optimize and consolidate their IT, Riverbed helps enterprises to build a fast, fluid and dynamic IT architecture that aligns with the business needs of the organization. Additional information about Riverbed (NASDAQ: RVBD) is available at www.riverbed.com.

Riverbed Technology, Inc. 199 Fremont Street San Francisco, CA 94105 Tel: (415) 247-8800 www.riverbed.com

Riverbed Technology Ltd. One Thames Valley Wokingham Road, Level 2 Bracknell. RG42 1NG United Kingdom Tel: +44 1344 31 7100

Riverbed Technology Pte. Ltd. 391A Orchard Road #22-06/10 Ngee Ann City Tower A Singapore 238873 Tel: +65 6508-7400

Riverbed Technology K.K. Shiba-Koen Plaza Building 9F 3-6-9, Shiba, Minato-ku Tokyo, Japan 105-0014 Tel: +81 3 5419 1990

http://www.riverbed.com/

Quick Start Guide for IBM® Tivoli Storage Manager® · QUICK START GUIDE Quick Start Guide for...

Documents

Transcript of Quick Start Guide for IBM® Tivoli Storage Manager® · QUICK START GUIDE Quick Start Guide for...