AWS Storage Gateway Userguide
AWS Storage Gateway Userguide
User Guide
API Version 2013-06-30
AWS Storage Gateway User Guide
Table of Contents
What Is AWS Storage Gateway? ...................................................................................................... 1
Are You a First-Time AWS Storage Gateway User? ..................................................................... 2
How AWS Storage Gateway Works ........................................................................................... 2
Volume Gateway Architecture (Gateway-Cached and Gateway-Stored) ................................... 2
Gateway-VTL Architecture .............................................................................................. 5
Available AWS Regions .......................................................................................................... 7
Pricing ................................................................................................................................. 8
Accessing AWS Storage Gateway ........................................................................................... 9
Getting Started ........................................................................................................................... 10
Recommended Reading ....................................................................................................... 10
Plan Your Gateway Deployment .............................................................................................. 11
Requirements ..................................................................................................................... 12
Supported Hypervisors and Host Requirements ................................................................ 12
Hardware Requirements ............................................................................................... 12
Supported iSCSI Initiators ............................................................................................. 13
Compatible Third-Party Backup Software for Gateway-VTL ................................................. 13
Storage Requirements .................................................................................................. 13
Network and Firewall Requirements ................................................................................ 14
Step 1: Sign Up ................................................................................................................... 17
Step 2: Deploy a VM and Activate the Gateway ......................................................................... 17
On-Premises Gateway .................................................................................................. 18
EC2 Gateway .............................................................................................................. 60
Setting Up Your Volume Gateway .................................................................................................... 71
Related Topics .................................................................................................................... 72
Step 1: Before You Begin ....................................................................................................... 72
Step 2: Configure Local Storage and Alarms ............................................................................ 72
Gateway-Cached ......................................................................................................... 73
Gateway-Stored .......................................................................................................... 76
Step 3: Create Volumes ........................................................................................................ 79
Gateway-Cached ......................................................................................................... 80
Gateway-Stored .......................................................................................................... 82
Step 4: Connect Your Volumes to Your Windows Client ................................................................ 85
Step 5: Test the Setup ........................................................................................................... 92
Gateway-Cached ......................................................................................................... 92
Gateway-Stored .......................................................................................................... 95
Step 6: Clean Up After the Example Exercise ........................................................................... 99
Where Do I Go from Here? .................................................................................................. 100
Sizing Your Gateway's Storage for Real-World Workloads .................................................. 100
Setting Up Your Gateway-VTL ...................................................................................................... 103
Related Topics ................................................................................................................... 103
Step 1: Before You Begin ..................................................................................................... 104
Step 2: Configure Local Storage ........................................................................................... 104
Step 3: Create Virtual Tapes ................................................................................................. 106
Step 4: Connect VTL Devices to Your Windows Client ............................................................... 108
Step 5: Test the Setup ........................................................................................................ 112
Symantec NetBackup 7.x ............................................................................................ 113
Symantec Backup Exec .............................................................................................. 127
Microsoft System Center 2012 R2 DPM ........................................................................ 131
Veeam Backup & Replication ....................................................................................... 134
Dell NetVault Backup .................................................................................................. 137
EMC NetWorker ........................................................................................................ 140
Step 6: Clean Up After the Example Exercise .......................................................................... 142
Where Do I Go from Here? .................................................................................................. 143
Managing Your Activated Gateway ................................................................................................ 144
Connecting iSCSI Initiators .................................................................................................. 144
Topics
• Are You a First-Time AWS Storage Gateway User? (p. 2)
• How AWS Storage Gateway Works (Architecture) (p. 2)
• Available AWS Regions (p. 7)
• AWS Storage Gateway Pricing (p. 8)
• Accessing AWS Storage Gateway (p. 9)
Welcome to the AWS Storage Gateway User Guide. AWS Storage Gateway connects an on-premises
software appliance with cloud-based storage to provide seamless integration with data security features
between your on-premises IT environment and the Amazon Web Services (AWS) storage infrastructure.
You can use the service to store data in the AWS cloud for scalable and cost-effective storage that helps
maintain data security. AWS Storage Gateway offers both volume-based and tape-based storage solutions:
• Volume gateways – Volume gateways provide cloud-backed storage volumes that you can mount as
Internet Small Computer System Interface (iSCSI) devices from your on-premises application servers.
The gateway supports the following volume configurations:
• Gateway-cached volumes – You store your data in Amazon Simple Storage Service (Amazon S3)
and retain a copy of frequently accessed data subsets locally. Gateway-cached volumes offer a
substantial cost savings on primary storage and minimize the need to scale your storage on-premises.
You also retain low-latency access to your frequently accessed data.
• Gateway-stored volumes – If you need low-latency access to your entire data set, you can configure
your on-premises gateway to store all your data locally and then asynchronously back up point-in-time
snapshots of this data to Amazon S3. This configuration provides durable and inexpensive off-site
backups that you can recover to your local data center or Amazon EC2. For example, if you need
replacement capacity for disaster recovery, you can recover the backups to Amazon EC2.
• Gateway–virtual tape library (VTL) – You can cost-effectively and durably archive backup data in
Amazon Glacier. Gateway-VTL provides a virtual tape infrastructure that scales seamlessly with your
business needs and eliminates the operational burden of provisioning, scaling, and maintaining a
physical tape infrastructure.
You may choose to run AWS Storage Gateway either on-premises, as a virtual machine (VM) appliance,
or in AWS, as an EC2 instance. You deploy your gateway on an EC2 instance to provision iSCSI storage
volumes in AWS. Gateways hosted on EC2 instances can be used for disaster recovery, data mirroring,
and providing storage for applications hosted on Amazon EC2.
For an architectural overview, see How AWS Storage Gateway Works (Architecture) (p. 2).
AWS Storage Gateway enables a wide range of use cases. For more information, go to the AWS Storage
Gateway detail page.
This documentation provides a Getting Started section that covers setup information common to all
gateways and also gateway-specific setup sections. The Getting Started section shows you how to deploy
and activate any gateway. The gateway-specific sections then discuss performing further setup for different
gateway types: volume gateways (that is, gateway-cached and gateway-stored volumes) and gateway-VTL.
Together, the Getting Started section and the gateway-specific sections show you how to get started, set
up a functioning gateway, and manage your gateway.
• Getting Started with AWS Storage Gateway (p. 10), for all gateways
The instructions in this guide primarily show the gateway operations by using the AWS Management
Console. If you want to perform these operations programmatically, see the AWS Storage Gateway API
Reference for information about the supported operations.
Topics
• Volume Gateway Architecture (Gateway-Cached and Gateway-Stored) (p. 2)
• Gateway–Virtual Tape Library (Gateway-VTL) Architecture (p. 5)
Topics
• Gateway-Cached Volume Architecture (p. 3)
Gateway-cached volumes can range from 1 GiB to 32 TiB in size and must be rounded to the nearest
GiB. Each gateway configured for gateway-cached volumes can support up to 32 volumes for a total
maximum storage volume of 1,024 TiB (1 PiB).
In the gateway-cached volume solution, AWS Storage Gateway stores all your on-premises application
data in a storage volume in Amazon S3.
The following diagram provides an overview of the AWS Storage Gateway-cached volume deployment.
After you've installed the AWS Storage Gateway software appliance—the virtual machine (VM)—on a
host in your data center and activated it, you can use the AWS Management Console to provision storage
volumes backed by Amazon S3. You can also provision storage volumes programmatically using the
AWS Storage Gateway API or the AWS SDK libraries. You then mount these storage volumes to your
on-premises application servers as iSCSI devices.
You also allocate disks on-premises for the VM. These on-premises disks serve the following purposes:
• Disks for use by the gateway as cache storage – As your applications write data to the storage
volumes in AWS, the gateway initially stores the data on the on-premises disks referred to as cache
storage before uploading the data to Amazon S3. The cache storage acts as the on-premises durable
store for data that is waiting to upload to Amazon S3 from the upload buffer.
The cache storage also lets the gateway store your application's recently accessed data on-premises
for low-latency access. If your application requests data, the gateway first checks the cache storage
for the data before checking Amazon S3.
You can use the following guidelines to determine the amount of disk space to allocate for cache
storage. Generally, you should allocate at least 20 percent of your existing file store size as cache
storage. Cache storage should also be larger than the upload buffer. This latter guideline helps ensure
cache storage is large enough to persistently hold all data in the upload buffer that has not yet been
uploaded to Amazon S3.
• Disks for use by the gateway as the upload buffer – To prepare for upload to Amazon S3, your
gateway also stores incoming data in a staging area, referred to as an upload buffer. Your gateway
uploads this buffer data over an encrypted Secure Sockets Layer (SSL) connection to AWS, where it
is stored encrypted in Amazon S3.
You can take incremental backups, called snapshots, of your storage volumes in Amazon S3. These
point-in-time snapshots are also stored in Amazon S3 as Amazon EBS snapshots. When you take a new
snapshot, only the data that has changed since your last snapshot is stored. You can initiate snapshots
on a scheduled or one-time basis. When you delete a snapshot, only the data not needed for any other
snapshots is removed.
You can restore an Amazon EBS snapshot to a gateway storage volume if you need to recover a backup
of your data. Alternatively, for snapshots up to 16 TiB in size, you can use the snapshot as a starting
point for a new Amazon EBS volume. You can then attach this new Amazon EBS volume to an Amazon
EC2 instance.
All gateway-cached volume data and snapshot data is stored in Amazon S3 encrypted at rest using
server-side encryption (SSE). However, you cannot access this data with the Amazon S3 API or other
tools such as the Amazon S3 console.
Gateway-stored volumes can range from 1 GiB to 16 TiB in size and must be rounded to the nearest GiB.
Each gateway configured for gateway-stored volumes can support up to 32 volumes and a total volume
storage of 512 TiB (0.5 PiB).
In the gateway-stored volume solution, you maintain your volume storage on-premises in your data center.
That is, you store all your application data on your on-premises storage hardware. Then, using features
that help maintain data security, the gateway uploads data to the AWS cloud for cost-effective backup
and rapid disaster recovery. This solution is ideal if you want to keep data locally on-premises, because
you need to have low-latency access to all your data, and also to maintain backups in AWS.
The following diagram provides an overview of the AWS Storage Gateway–stored volume deployment.
After you've installed the AWS Storage Gateway software appliance—the virtual machine (VM)—on a
host in your data center and activated it, you can create gateway storage volumes and map them to
on-premises direct-attached storage (DAS) or storage area network (SAN) disks.You can start with either
new disks or disks already holding data. You can then mount these storage volumes to your on-premises
application servers as iSCSI devices. As your on-premises applications write data to and read data from
a gateway's storage volume, this data is stored and retrieved from the volume's assigned disk.
To prepare data for upload to Amazon S3, your gateway also stores incoming data in a staging area,
referred to as an upload buffer. You can use on-premises DAS or SAN disks for working storage. Your
gateway uploads data from the upload buffer over an encrypted Secure Sockets Layer (SSL) connection
to the AWS Storage Gateway service running in the AWS cloud.The service then stores the data encrypted
in Amazon S3.
You can take incremental backups, called snapshots, of your storage volumes. The gateway stores these
snapshots in Amazon S3 as Amazon EBS snapshots. When you take a new snapshot, only the data that
has changed since your last snapshot is stored. You can initiate snapshots on a scheduled or one-time
basis. When you delete a snapshot, only the data not needed for any other snapshot is removed.
You can restore an Amazon EBS snapshot to an on-premises gateway storage volume if you need to
recover a backup of your data. You can also use the snapshot as a starting point for a new Amazon EBS
volume, which you can then attach to an Amazon Elastic Compute Cloud (Amazon EC2) instance.
The following diagram provides an overview of the AWS Storage Gateway–VTL deployment.
• Virtual tape – Virtual tape is analogous to a physical tape cartridge. However, virtual tape data is stored
in the AWS cloud. Like physical tapes, virtual tapes can be blank or can have data written on them.
You can create virtual tapes either by using the AWS Storage Gateway console or programmatically
by using the AWS Storage Gateway API. Each gateway can contain up to 1500 tapes or up to 1 PiB
of total tape data at a time. The size of each virtual tape, which you can configure when you create the
tape, is between 100 GiB and 2.5 TiB.
• Virtual tape library (VTL) – A VTL is analogous to a physical tape library available on-premises with
robotic arms and tape drives, including the collection of virtual tapes stored within the library. Each
gateway-VTL comes with one VTL.
The virtual tapes that you create appear in your gateway's VTL. Tapes in the VTL are backed up by
Amazon S3. As your backup software writes data to the gateway, the gateway stores data locally and
then asynchronously uploads it to virtual tapes in your VTL—that is, Amazon Simple Storage Service
(Amazon S3).
• Tape drive – A VTL tape drive is analogous to a physical tape drive that can perform I/O and seek
operations on a tape. Each VTL comes with a set of 10 tape drives, which are available to your
backup application as iSCSI devices.
• Media changer – A VTL media changer is analogous to a robot that moves tapes around in a physical
tape library's storage slots and tape drives. Each VTL comes with one media changer, which is
available to your backup application as an iSCSI device.
• Virtual tape shelf (VTS) – A VTS is analogous to an off-site tape holding facility.You can archive tapes
from your gateway's VTL to the VTS and, if needed, retrieve tapes from the VTS back to your gateway's
VTL.
• Archiving tapes – When your backup software ejects a tape, your gateway moves the tape to the
VTS for long-term storage. The VTS is located in the AWS region in which you activated the gateway.
Tapes in the VTS are stored in Amazon Glacier, an extremely low-cost storage service for data
archiving and backup. For more information, go to Amazon Glacier.
• Retrieving tapes – Tapes archived to the VTS cannot be read directly. To read an archived tape,
you must first retrieve it to your gateway-VTL either by using the AWS Storage Gateway console or
by using the AWS Storage Gateway API. A retrieved tape will be available in your VTL in about 24
hours.
You have one VTS in your account per AWS region. For example, if you create multiple gateways in
the same AWS region, one VTS will hold ejected tapes for all the gateways. If you create gateways in
different AWS regions, you will have one VTS per AWS region.
After you deploy and activate a gateway-VTL, you mount the virtual tape drives and media changer on
your on-premises application servers as iSCSI devices. You create virtual tapes as needed and then use
your existing backup software application to write data to the virtual tapes. The media changer loads and
unloads the virtual tapes into the virtual tape drives for read and write operations.
• Cache storage – The cache storage acts as the durable store for data that is waiting to upload to
Amazon S3 from the upload buffer.
If your application reads data from a virtual tape, the gateway saves the data to the cache storage. The
gateway stores recently accessed data in the cache storage for low-latency access. If your application
requests tape data, the gateway first checks the cache storage for the data before downloading the
data from AWS.
• Upload buffer – The upload buffer provides a staging area for the gateway before it uploads the data
to a virtual tape. The upload buffer is also critical for creating recovery points that you can use to recover
tapes from unexpected failures. For more information, see You Need to Recover a Virtual Tape from
a Malfunctioning Gateway-VTL (p. 309).
As your backup application writes data to your gateway, the gateway copies data to both the cache storage
and the upload buffer before acknowledging completion of the write operation to your backup application.
For guidelines to determine the amount of disk space you should allocate for the cache storage and
upload buffer, see Step 2.3.1: Decide the Amount of Local Disk Storage (p. 26).
Following are the available regions for gateways deployed an EC2 instance.
Additionally, you can use the AWS Storage Gateway API to programmatically configure and manage
your gateways. For more information about the API, see API Reference for AWS Storage Gateway (p. 332).
You can also use the AWS SDKs to develop applications that interact with AWS Storage Gateway. The
AWS SDKs for Java, .NET, and PHP wrap the underlying AWS Storage Gateway API to simplify your
programming tasks. For information about downloading the SDK libraries, go to Sample Code Libraries.
Next Step
This Getting Started section provides instructions for you to download, deploy, and activate a gateway.
The steps in these instructions are common to all the storage solutions offered by AWS Storage Gateway.
After completing these steps, you can proceed to one of the gateway-specific sections for additional setup
instructions.
As you follow the steps in this Getting Started section, you will use the Setup and Activate Gateway
wizard in the AWS Storage Gateway console.
At several steps in the wizard, you perform tasks outside of the console and then return. If your session
times out or the browser closes, you can return to the console.
Recommended Reading
Before you get started, we recommend you read the following sections in this guide:
Next Step
To deploy an AWS Storage Gateway solution, you first need to decide on the following two things:
1. Storage solution – Depending on your need, you can choose from one of the following storage
solutions:
• Volume gateway (gateway-cached or gateway-stored) – Volume gateways let you create storage
volumes in the AWS cloud that your on-premises applications can access as Internet Small Computer
System Interface (iSCSI) targets. There are two options—gateway-cached or gateway-stored.
With gateway-cached volumes, you store volume data in AWS, with a small portion of recently
accessed data in the cache on-premises.This approach enables low-latency access to your frequently
accessed dataset and also provides seamless access to your entire dataset stored in AWS. This
type of data access lets you scale your storage resource without having to provision additional
hardware.
With gateway-stored volumes, you store the entire set of volume data on-premises and store periodic
point-in-time backups (snapshots) in AWS. In this model, your on-premises storage is primary,
delivering low-latency access to your entire dataset, and AWS storage is the backup that you can
restore in the event of a disaster in your data center.
Additionally, as you configure a host to deploy a gateway software appliance, you will need to allocate
sufficient storage for the gateway VM.
Before you continue to the next step, make sure you have done the following:
1. For a gateway deployed on-premises, you have decided the type of host you want to set up (VMware
ESXi Hypervisor or Microsoft Hyper-V) and set it up. For more information, see Requirements (p. 12).
If you deploy the gateway behind a firewall, you must make sure certain ports are accessible to the
gateway VM. For more information, see Requirements (p. 12). The following topics provide steps for
configuring the host:
• Configuring a VMware ESXi Host for AWS Storage Gateway (p. 365)
• Configuring a Hyper-V Host for AWS Storage Gateway (p. 370)
2. For a gateway-VTL, you have installed client backup software. For more information, Compatible
Third-Party Backup Software for Gateway-VTL (p. 13).
Next Step
Requirements
Unless otherwise noted, the following requirements are common to all gateway configurations.
Topics
• Supported Hypervisors and Host Requirements (p. 12)
• Hardware Requirements (p. 12)
• Supported iSCSI Initiators (p. 13)
• Compatible Third-Party Backup Software for Gateway-VTL (p. 13)
• Storage Requirements (p. 13)
• Network and Firewall Requirements (p. 14)
AWS Storage Gateway supports the following hypervisor versions and hosts:
• VMware ESXi Hypervisor (version 4.1, 5.0, 5.1, 5.5 or 6.0)—A free version of VMware is available on
the VMware website. You will also need a VMware vSphere client to connect to the host.
• Microsoft Hyper-V Hypervisor (version 2008 R2, 2012, or 2012 R2)—A free, stand-alone version of
Hyper-V is available at the Microsoft Download Center. You will need a Microsoft Hyper-V Manager
on a Microsoft Windows client computer to connect to the host.
• EC2 instance—AWS Storage Gateway provides an Amazon Machine Image (AMI) that contains the
gateway VM image. Only gateway-cached volumes and gateway–virtual tape libraries (gateway-VTLs)
can be deployed on Amazon EC2. For information about how to deploy a gateway on Amazon EC2,
see Amazon EC2 Gateway (p. 60).
Hardware Requirements
When deploying your gateway on-premises, you must make sure that the underlying hardware on which
you are deploying the gateway VM is able to dedicate the following resources:
For information about how your hardware affects the performance of the gateway VM, see AWS Storage
Gateway Limits (p. 362).
When deploying your gateway on Amazon EC2, you must use the m3, i2, c3, c4, r3, d2, and m4 instance
types and the instance size must be at least size xlarge. You must select one of these instance types
for the gateway to function. For more information, go to AWS Storage Gateway in AWS Marketplace.
Important
Storage Gateway does not support Microsoft Multipath I/O (MPIO) from Windows clients.
Although AWS Storage Gateway enables applications that are clustered using Windows Server
Failover Clustering (WSFC) to use the iSCSI initiator to access your gateway's volumes,
connecting multiple hosts to the same iSCSI target is not supported.
Storage Requirements
In addition to 75 GB disk space for the VM, you will also need additional disks for the gateway:
• For gateway-cached volume configuration, you will need storage for the local cache and an upload
buffer.
• For gateway-stored volume configuration, you will need storage for your entire dataset and an upload
buffer.
• For gateway-VTL configuration, you will need storage for the local cache and an upload buffer.
For more information about how to add disks, see Step 2.3: Provision Local Disk Storage for the Gateway
VM (VMWare) (p. 26).
For information about gateway limits, see AWS Storage Gateway Limits (p. 362).
Topics
• Port Requirements (p. 14)
• Allowing AWS Storage Gateway Access through Firewalls and Routers (p. 16)
Port Requirements
AWS Storage Gateway requires the following ports for its operation.
client-cp.storagegateway.region.amazonaws.com:443
dp-1.storagegateway.region.amazonaws.com:443
anon-cp.storagegateway.region.amazonaws.com:443
proxy-app.storagegateway.region.amazonaws.com:443
storagegateway.region.amazonaws.com:443
The following table provides a list of region strings for the available regions.
Depending on your gateway's region, you replace region in the endpoint with the corresponding region
string. For example, if you create a gateway in the US West (Oregon) region, the endpoint looks like this:
storagegateway.us-west-2.amazonaws.com:443.
Next Step
Part of the sign-up procedure involves receiving a phone call and entering a PIN using the phone
keypad.
Next Step
If you are deploying the gateway on-premises, you download and deploy the gateway virtual machine
(VM) and then activate the gateway. If you are deploying the gateway on an Amazon EC2 instance, you
launch an Amazon Machine Image (AMI) that contains the gateway VM image and then activate the
gateway.
Topics
• On-Premises Gateway (p. 18)
• Amazon EC2 Gateway (p. 60)
Next Step
Depending on whether you are deploying your gateway on premises or on Amazon EC2, click one of the
following links.
On-Premises Gateway
When you select Deploy a New Gateway to deploy a gateway on-premises, the setup wizard asks you
to choose a gateway configuration.
Next Step
Depending on the hypervisor host you provisioned in your data center, click one the following links.
• Step 2.1: Provision a VMware Host to Deploy the AWS Storage Gateway VM (p. 19)
• Step 2.1: Provision a Hyper-V Host to Deploy the AWS Storage Gateway VM (p. 38)
VMware Host
This section shows you how to provision an on-premises VMware host, download and deploy a gateway.
Topics
• Step 2.1: Provision a VMware Host to Deploy the AWS Storage Gateway VM (p. 19)
• Step 2.2: Download and Deploy the AWS Storage Gateway VM on Your Host (p. 19)
• Step 2.3: Provision Local Disk Storage for the Gateway VM (VMWare) (p. 26)
• Step 2.4: Activate the AWS Storage Gateway (p. 33)
• Using AWS Storage Gateway with VMware High Availability (p. 38)
Next Step
Step 2.1: Provision a VMware Host to Deploy the AWS Storage Gateway VM (p. 19)
Step 2.1: Provision a VMware Host to Deploy the AWS Storage Gateway
VM
If you have not provisioned a host to deploy the gateway VM, provision a host now.
To provision a host
Note
If you plan to deploy AWS Storage Gateway using VMware High Availability (HA) for failover
protection, see Using AWS Storage Gateway with VMware High Availability (p. 38). In this
tutorial exercise, you deploy your AWS Storage Gateway VM on a single host with no
clustering or failover provision.
3. In the setup wizard, click Continue.
Next Step
Step 2.2: Download and Deploy the AWS Storage Gateway VM on Your Host (p. 19)
Step 2.2: Download and Deploy the AWS Storage Gateway VM on Your Host
The AWS Storage Gateway virtual machine is available as a VMware ESX .ova package. This section
shows you how to perform the following tasks.
Note
For gateways deployed on-premises, restoring a snapshot of a gateway VM that is taken from
your hypervisor is not supported.
Topics
• Step 2.2.1: Download the AWS Storage Gateway VM (p. 20)
• Step 2.2.2: Deploy the AWS Storage Gateway VM to Your Host (p. 20)
• Step 2.2.3: Synchronize VM Time with Host Time (p. 23)
To download the VM
1. In the AWS Storage Gateway console's Setup and Activate Gateway wizard, navigate to the
DOWNLOAD AND DEPLOY VM page.
2. Select I want to run the AWS Storage Gateway on VMware ESXi, and then click Continue.
3. Click Download to download a .zip file that contains the .ova file. Extract and save the .zip file
to a location on your computer.
Note
The .zip file is over 500 MB in size and may take some time to download, depending on
your network connection.
1. To connect to your hypervisor host, start the VMware vSphere client on Windows, type your host's
IP and your credentials in the login dialog box, and then click Login.
2. Deploy the AWS Storage Gateway VM on the host using the following steps.
a. On the File menu of the vSphere client, click Deploy OVF Template.
Doing this opens the Deploy OVF Template wizard, a series of steps to provide information
required to deploy the VM.
b. In the Source pane, provide the file path to the AWS Storage Gateway .ova package, and then
click Next.
Although the vSphere client displays this VM name, AWS Storage Gateway does not use this
name.
e. The following Datastore pane appears only if your host has multiple data stores. In this pane,
you select the data store where you want to deploy the VM, and then click Next. If your host
has only one data store, skip to the next step.
A data store is a virtual representation of underlying physical storage resources. The following
example shows a host that has two data stores: datastore1 and datastore2.
f. In the Disk Format pane, select Thick provisioned format, and then click Next.
When you use thick provisioning, the disk storage is allocated immediately, resulting in better
performance. In contrast, thin provisioning allocates storage on demand. On-demand allocation
can affect the normal functioning of AWS Storage Gateway. For AWS Storage Gateway to
function properly, the VM disks must be stored in thick-provisioned format.
h. View the details of the new VM to verify the information about the VM.
i. Depending on the state of your vSphere client, you might need to click the Inventory icon
to view the host object that contains the new VM.
ii. Expand the host object to view the details of the new VM.
To successfully activate your gateway, you must ensure that your VM time is synchronized to the host
time, and that the host time is correctly set. In this section, you first synchronize the time on the VM to
the host time. Then you check the host time and, if needed, set the host time and configure the host to
synchronize its time automatically to a Network Time Protocol (NTP) server.
Important
Synchronizing the VM time with the host time is required for successful gateway activation.
a. In the vSphere client, right-click the name of your gateway VM and click Edit Settings.
b. Click the Options tab, and click VMware Tools in the options list.
c. Check the Synchronize guest time with host option, and then click OK.
It is important to make sure that your host clock is set to the correct time. If you have not configured
your host clock, perform the following steps to set and synchronize it with an NTP server.
a. In the VMware vSphere client, select the vSphere host node in the left pane, and then click the
Configuration tab.
b. Select Time Configuration in the Software panel, and then click the Properties link.
c. In the Date and Time panel, set the date and time.
i. Click Options in the Time Configuration dialog box, and then in the NTP Daemon (ntpd)
Options dialog box, click NTP Settings in the left pane.
iv. In the NTP Daemon (ntpd) Options dialog box, click General in the left pane.
v. In the Service Commands pane, click Start to start the service.
Note that if you change this NTP server reference or add another later, you will need to
restart the service to use the new server.
Next Step
Step 2.3: Provision Local Disk Storage for the Gateway VM (VMWare) (p. 26)
Step 2.3: Provision Local Disk Storage for the Gateway VM (VMWare)
Next, you allocate local storage for your deployed gateway VM. After you activate your gateway, you
configure this local storage for the gateway's use.
Topics
• Step 2.3.1: Decide the Amount of Local Disk Storage (p. 26)
• Step 2.3.2: Provision Local Disk Storage (p. 27)
• Step 2.3.3: Configure the AWS Storage Gateway VM to Use Paravirtualized Disk Controllers (p. 32)
In this step, you decide the number and size of disks to allocate for your gateway, as follows:
You need at least two disks to begin with. The following table recommends sizes for local disk storage
for your deployed gateway.
Before going to the next step, decide the number and size of disks to allocate. You can add more local
storage after you set the gateway up, and as your workload demands. If you're not sure what number
and size of disks to use, provision two local disks with the minimum recommended size for your gateway
type.
If you plan to deploy your gateway in production, you should consider your real workload in determining
disk sizes. For information about disk size guidelines, see Managing the Upload Buffer (p. 238) and
Managing Cache Storage (p. 243).
For more information about how gateways use local storage, see How AWS Storage Gateway Works
(Architecture) (p. 2).
In the next step, you allocate the local disk storage to the gateway VM you deployed.
You can add disks from direct attached storage (DAS) or from a storage area network (SAN). This section
tells how to add a virtual disk from a DAS. For instructions on attaching iSCSI volumes from an existing
SAN for this step, see To add a new iSCSI target (p. 366).
Repeat the following procedure for each local disk you planed in the preceding step.
1. Start the VMware vSphere client, and then connect to your host.
2. In the client, right-click the name of your gateway VM, and then click Edit Settings.
3. Click the Hardware tab of the Virtual Machine Properties dialog box, and then click Add to add a
device.
a. In the Device Type pane, click Hard Disk to add a disk, and then click Next.
b. In the Select a Disk pane, select Create a new virtual disk, and then click Next.
d. Click Next, and in the Advanced Options pane, accept the default values, and then click Next.
e. In the Ready to Complete pane, accept the default values, and then click Finish.
f. In the Virtual Machine Properties dialog box, click OK to complete adding the disk.
a. In the client, right-click the name of your gateway VM and click Edit Settings.
b. In the Hardware tab of the Virtual Machine Properties dialog box, verify the disks in the
hardware list.
For example, the following screenshot shows two disks added to the gateway. The disks you
add appear in the AWS Storage Gateway console as SCSI (0:0), SCSI (0:1), and so on.
Step 2.3.3: Configure the AWS Storage Gateway VM to Use Paravirtualized Disk Controllers
In this task, you set the iSCSI controller so that the VM uses paravirtualization. Paravirtualization is a
mode where the gateway VM works with the host operating system so the console can identify the virtual
disks that you add to your VM.
Note
You must complete this step to avoid issues in identifying these disks when you configure them
in the gateway console.
1. In the VMware vSphere client, right-click the name of your gateway VM, and then click Edit Settings.
2. In the Virtual Machine Properties dialog box, click the Hardware tab, select the SCSI controller
0, and then click Change Type.
3. In the Change SCSI Controller Type dialog box, select the VMware Paravirtual SCSI controller
type, and then click OK.
Next Step
Your gateway VM icon now has a green arrow associated with it, indicating that you have turned
on the VM.
Note
The IP address of your gateway appears on the Summary tab. After turning on
the VM, it might take a few moments for the IP address to appear.
i. In the AWS Storage Gateway console's Setup and Activate Gateway wizard, navigate to
the ACTIVATE GATEWAY page.
If the wizard has not already started, click the Set up and Activate a New Gateway button,
and then click Continue in each wizard step until you reach that page.
ii. In the Enter IP address text box, type the IP address of your gateway, and then click
Proceed to Activation.
Note
During activation, your browser connects to the gateway. If activation fails, check
that the IP address you entered is correct. If the IP address is correct, confirm that
your network is configured to let your browser access the gateway VM.
iii. To complete the activation process, enter the information listed on the activation page. The
activation page you see depends on your gateway configuration.
• AWS Region determines where AWS stores your snapshots (for gateway-cached volumes)
or virtual tapes (for gateway-VTLs). This region is the one in which you deployed your
gateway.
• Gateway Time Zone specifies the time zone to use for your gateway.
• Gateway Name identifies your gateway. You use this name to manage your gateway in
the console; you can change it after the gateway is activated. This name must be unique
to your account.
• Medium Changer Type specifies the type of medium changer to use for your backup
software (available for gateway-VTLs only).
Important
The type of medium changer you select depends on the backup software you
plan to use. The following table shows which medium changer to select for your
backup software. This list includes third-party backup software that has been
tested and found to be compatible with gateway-VTL.
Note
You must select the medium changer that is recommended for your
backup software. Other medium changers might not function properly.
You can select a different medium changer after the gateway is
activated. For more information, see Selecting a Medium Changer After
Gateway Activation (p. 360).
• Tape Drive Type specifies the type of tape drive used by this gateway (available for
gateway-VTLs only).
Note
AWS Storage Gateway is supported in the following regions.
The following screenshot shows the activation page for gateway-cached volumes or
gateway-stored volumes.
When the gateway is successfully activated, the AWS Storage Gateway console displays a link to
the activated gateway in the Gateways section of the Navigation pane. To display the entire console,
click the gateway you just added. You continue setup by configuring local storage for your gateway.
How you configure storage depends on the type of gateway you are setting up.
If activation is not successful, see Troubleshoot Issues with Your Gateways (p. 297) for possible
solutions.
Next Step
You have completed the download, deployment, and activation steps common to all gateways. The
remaining setup steps are gateway-specific. To continue the setup process, choose one of the following
options:
• Step 2: Configure Local Storage and Alarms (Gateway-Cached and Gateway-Stored) (p. 72)
• Step 2: Configure Local Storage and Alarms (Gateway-VTL) (p. 104)
To use AWS Storage Gateway with VMware HA, we recommend doing the following things:
• Deploy the gateway Open Virtualization Application (OVA) on only one host in a cluster.
• When deploying the OVA, select a data store that is not local to one host. Instead, use a data store
that is accessible to all hosts in the cluster. If you select a data store that is local to a host and the host
fails, then the data source may not be accessible to other hosts in the cluster and the failover may not
succeed.
• Follow the recommended iSCSI settings to prevent your initiator from disconnecting from storage
volume targets during failover. In a failover event, it could take between a few seconds to several
minutes for a gateway VM to start in a new host in the failover cluster. The recommended iSCSI timeouts
for both Windows and Linux clients are greater than the typical time it takes for failover to occur. For
more information on customizing Windows clients' timeout settings, see Customizing Your Windows
iSCSI Settings (p. 147). For more information on customizing Linux clients' timeout settings, see
Customizing Your Linux iSCSI Settings (p. 151).
• With clustering, if you deploy the OVA to the cluster, you will be asked to select a host. Alternately, you
can deploy directly to a host in a cluster.
Hyper-V Host
This section shows you how to provision an on-premises Hyper-V host, download and deploy a gateway.
Topics
• Step 2.1: Provision a Hyper-V Host to Deploy the AWS Storage Gateway VM (p. 38)
• Step 2.2: Download and Deploy the AWS Storage Gateway VM on Your Host (p. 39)
• Step 2.3: Provision Local Storage for the AWS Storage Gateway VM (Hyper-V) (p. 48)
• Step 2.4: Activate Your Storage Gateway (p. 53)
Next Step
Step 2.1: Provision a Hyper-V Host to Deploy the AWS Storage Gateway VM (p. 38)
Step 2.1: Provision a Hyper-V Host to Deploy the AWS Storage Gateway
VM
If you have not provisioned a host to deploy the gateway VM, provision a host now.
To provision a host
Next Step
Step 2.2: Download and Deploy the AWS Storage Gateway VM on Your Host (p. 39)
Step 2.2: Download and Deploy the AWS Storage Gateway VM on Your Host
The AWS Storage Gateway virtual machine is available as a Hyper-V downloadable package.This section
shows you how to provision an on-premises Hyper-V host, download and deploy a gateway.
Note
For gateways deployed on-premises, restoring a snapshot of a gateway VM that is taken from
your hypervisor is not supported.
Topics
• Step 2.2.1: Download the AWS Storage Gateway VM (p. 39)
• Step 2.2.2: Deploy the AWS Storage Gateway VM to Your Host (p. 40)
To download the VM
1. In the AWS Storage Gateway console's Setup and Activate Gateway wizard, navigate to the
DOWNLOAD AND DEPLOY VM page.
2. Select the version of Microsoft Hyper-V hypervisor you want to run your AWS Storage Gateway VM
on, and then click Continue. In this example, we select I want to run the AWS Storage Gateway
on Microsoft Hyper-V 2008 R2.
3. Click Download to download a .zip file that contains the VM. Extract and save the .zip file to a
location on your computer, and make note of the location of the folder that was created.
Note
The .zip file is over 500 MB in size and might take some time to download, depending on
your network connection.
To work with your hypervisor host, you must connect to it. After you connect to it, you specify locations
where VM items are stored, import the VM, and then configure a network for it.
In this exercise, we use Microsoft Hyper-V 2008 R2 Manager to show you how to deploy the VM. Depending
on the version of Hyper-V Manager you are using, the screenshots in the exercise might look slightly
different from what you see in your UI. However, the procedure is similar for all versions of Microsoft
Hyper-V that AWS Storage Gateway supports. For information about the Hyper-V versions that AWS
Storage Gateway supports, see Requirements (p. 12).
1. Start the Microsoft Hyper-V Manager on your Windows client, and then in the Actions pane, click
Connect to Server.
2. In the Select Computer dialog box, select Another Computer, enter the IP address or host name,
and then click OK.
Note
In this exercise, we use hyperv-server as a host. Your host name will be different. If you
don't find your host name in the Select Computer dialog box, you might need to add an
entry to your hosts file so that Hyper-V Manager can resolve the server name.
Now that you are connected to your host, the next step is to create folders on the host to store the
downloaded source VM, the imported running VM, and virtual hard disks for the running VM.
1. Create locations on the hypervisor host for the gateway virtual hard disks and VM.
Note
For Microsoft Hyper-V 2012, this step can be found in the Choose Folders to Store Virtual
Hard Disks dialog box.
For example, assuming the name of the host in this exercise and the C drive as the correct drive
for the host, in the Start menu you can type \\hyperv-server\c$.
b. Create a folder called getting-started with two subfolders, unzippedSourceVM and
gateway.
2. Configure the Hyper-V Manager to point to the gateway folder you created. The running VM stores
its configuration in this folder.
b. In the Hyper-V Settings dialog box, configure the location of the virtual hard disks and virtual
machines.
i. In the left pane, under Server, select the Virtual Hard Disks setting.
ii. Browse to find the gateway folder you created earlier. Note that you are browsing on the
hypervisor (host) server.
iii. In the left pane, select the Virtual Machines setting under Server, and then browse to set
the location to the same gateway folder and click OK.
To import the VM
1. Copy the unzipped source VM files to the folder you created on the host computer. In this exercise,
the path is
\\hyperv-server\c$\getting-started\unzippedSourceVM\AWS-Storage-Gateway.
2. Import the AWS Storage Gateway VM to the host.
a. In the Hyper-V Manager, select the host hyperv-server in the left pane, which shows the console
tree.
b. In the Actions menu, click Import Virtual Machine.
Caution
You must point to the correct folder for the import to succeed. The correct folder
to select (AWS-Storage-Gateway) contains three other folders (Snapshots,
Virtual Hard Disks, Virtual Machines) and one file (config.xml).
Depending on how you unzip the gateway source files, you might end up with an
extra folder level. For help troubleshooting imports, see Troubleshooting Your
Microsoft Hyper-V Setup (p. 376).
ii. Select Copy the virtual machine (create a new unique ID).
Note
For Microsoft Hyper-V 2012, this step can be found in the Choose Import Type
tab.
iii. Check Duplicate all files so the same virtual machine can be imported again.
iv. Click Import.
Caution
It is important to select the Copy the virtual machine (create a new unique ID)
and Duplicate all files so the same virtual machine can be imported again
options, especially if you intend to reuse the unzipped gateway source files.
Important
You must have 75 GiB of disk space for installation of the VM image and system
data.
3. Rename the virtual machine to avoid confusion with other virtual machines that you might import to
the host.
5. Configure the host time if you have not already done so, and then click OK.
It is important to make sure that your host clock is set to the correct time. The following steps show
you how to set the time by using the Server Configuration Tool (Sconfig.cmd). For more information
about Sconfig.cmd, go to Configure a Server Core Server with Sconfig.cmd. (Depending on the
version of Microsoft Hyper-V you are running, you might be able to set the time in other ways.)
a. Access the Sconfig.cmd tool by either using the hypervisor host console or logging in remotely.
Note
In this exercise, we assume the host does not have virtual network settings configured. If
you already have a virtual network configured, go to step 2.
a. In the Actions menu, under the hypervisor host name (for example, hyperv-server), click
Virtual Network Manager.
b. In the Virtual Network Manager dialog box, select New virtual network.
c. Select External as the virtual network type, and then click Add.
c. In the Settings window, select Network Adapter. The Network Adapter should have a status
of Not connected.
d. In the Network box at right, select a network, and then click OK. In the following screenshot,
Virtual Network 1 is selected.
Next Step
Step 2.3: Provision Local Storage for the AWS Storage Gateway VM (Hyper-V) (p. 48)
Step 2.3: Provision Local Storage for the AWS Storage Gateway VM
(Hyper-V)
Next, you allocate local storage for your deployed gateway VM. After you activate your gateway, you
configure this local storage for the gateway's use.
Topics
• Step 2.3.1: Decide the Amount of Local Disk Storage (p. 48)
• Step 2.3.2: Provision Local Disk Storage (p. 49)
In this step, you decide the number and size of disks to allocate for your gateway, as follows:
• Depending on the storage solution you deploy (see Plan Your AWS Storage Gateway
Deployment (p. 11)), the gateway requires the following additional storage:
• Gateway-VTLs and gateway-cached volumes require one or more disks for cache storage.
• Gateway-stored volumes require one or more disks for volume storage—one local disk for each
volume created on the gateway.
You will need at least two disks to begin with. The following table recommends sizes for the local disk
storage you will allocate in this step.
Before going to the next step, decide the number and size of disks to allocate. You can add more local
storage after you set the gateway up, as your workload demands. If you're not sure what number and
size of disks to use, provision two local disks with minimum recommended size.
If you plan to deploy your gateway in production, you should consider your real workload in determining
disk sizes. For information about disk size guidelines, see Managing the Upload Buffer (p. 238) and
Managing Cache Storage (p. 243).
For more information about how gateways use local storage, see How AWS Storage Gateway Works
(Architecture) (p. 2).
In the next step, you allocate the local disk storage to the gateway VM you deployed.
You can add disks from direct attached storage (DAS) or from a storage area network (SAN). This section
tells how to add a virtual disk from a DAS. For instructions on attaching iSCSI volumes from an existing
SAN for this step, see To add a new iSCSI target (p. 366).
Repeat the following procedure for each local disk you planned in the preceding step.
1. Start the Microsoft Hyper-V Manager, and then connect to the hypervisor.
2. In the Virtual Machines list, select the virtual machine ExampleGatewayHyperV.
3. In the Actions pane of your gateway, select Settings.
4. In the Settings window, select SCSI Controller, and then click Add.
6. In the New Virtual Hard Disk Wizard, create a new virtual hard disk.
When you use fixed-size provisioning, the disk storage is allocated immediately, resulting in
better performance. If you don’t use fixed-size provisioning, the storage is allocated on demand.
On-demand allocation can affect the functioning of AWS Storage Gateway. For AWS Storage
Gateway to function properly, the VM disks must be stored in fixed-size provisioned format.
c. On the Specify Name and Location page, specify a name and location for the virtual hard disk.
d. In the Configure Disk page, specify the disk size you previously decided, and click Finish.
Note
The disk sizes used in these examples in this documentation are not suitable for
real-world workloads. If your setup is a trial setup, you can use small disk sizes.
e. After the virtual disk is created, verify that Hard Drive shows up under SCSI controller.
f. Click SCSI Controller to prepare to add another hard drive, and then click OK.
Warning
When you add an additional hard drive, you must first click SCSI Controller and then
follow the steps in the following procedure. Clicking New when viewing the details of
an existing hard drive will replace the existing drive.
a. Start the Microsoft Hyper-V Manager and connect to the hypervisor if it is not already started.
b. In the Virtual Machines list, select the virtual machine ExampleGatewayHyperV.
c. In the Actions pane, select Settings, and then in the Hardware pane select SCSI Controller
and verify there are two disks under the SCSI controller.
The two disks you created are used later in the AWS Storage Gateway console and appear as
SCSI (0:0) and SCSI (0:1) in drop-down lists. In the following example, the CacheStorage.vhd
disk is selected and is SCSI (0:0).
Next Step
a. Start the Microsoft Hyper-V Manager and connect to the hypervisor if it is not already connected.
b. In the Virtual Machines list, select the virtual machine you deployed, ExampleGatewayHyperV.
c. In the Actions pane for your gateway, click Start.
The Virtual Machine Connection window appears. If this window does not appear, click Connect
in the Actions pane for your gateway.
d. If an authentication window appears, type the user name and password provided to you by the
hypervisor administrator.
e. After a few moments, the virtual machine is ready for you to log in.
The example following shows the login prompt you see when the VM is ready.
vi. In the AWS Storage Gateway Static IP Address Configuration menu, select option 1,
View Network Configuration.
In the example below, the IP address is 10.61.64.130. Your gateway's IP address will be
different.
ix. Press the Enter key, and follow the prompts to exit the configuration menu.
i. In the AWS Storage Gateway console's Setup and Activate Gateway wizard, navigate to
the ACTIVATE GATEWAY page.
If the wizard has not already started, in the navigation pane, click the Deploy a New Gateway
link then click Continue in each wizard step in the Setup and Activate Gateway until you
reach that page.
ii. Type the IP address of your gateway, and click Proceed to Activation. Make a note of the
IP address, because you will need it later when you access your devices.
Note
During activation, your browser connects to the gateway. If activation fails, check
that the IP address you entered is correct. If the IP address is correct, confirm that
your network is configured to allow your browser to access the gateway VM.
iii. To complete the activation process, enter the information listed following on the activation
page. The activation page you see depends on your gateway configuration.
• AWS Region determines where AWS stores your snapshots (for gateway-cached volumes)
or virtual tapes (for gateway-VTLs).You select the region in which to deploy your gateway
in the AWS Region box. You cannot change the region after the gateway is activated.
• Gateway Time Zone specifies the time zone to use for your gateway.
• Gateway Name identifies your gateway. You use this name to manage your gateway in
the console; you can change it after the gateway is activated. This name must be unique
to your account.
• Medium Changer Type specifies the type of medium changer to use for your backup
software (available for gateway-VTLs only).
Important
The type of medium changer you select depends on the backup software you
plan to use. The following table shows which medium changer to select for your
backup software. This list includes third-party backup software that has been
tested and found to be compatible with gateway-VTL.
Note
You must select the medium changer that is recommended for your
backup software. Other medium changers might not function properly.
You can select a different medium changer after the gateway is
activated. For more information, see Selecting a Medium Changer After
Gateway Activation (p. 360).
• Tape Drive Type specifies the type of tape drive used by this gateway (available for
gateway-VTLs only).
Note
AWS Storage Gateway is supported in the following regions.
The following screenshot shows the activation page for gateway-cached volumes or
gateway-stored volumes.
When the gateway is successfully activated, the AWS Storage Gateway console displays a link to
the activated gateway in the Gateways section of the Navigation pane. To display the entire console,
click the gateway you just added. You continue setup by configuring local storage for your gateway.
How you configure storage depends on the type of gateway you are setting up.
If activation is not successful, see Troubleshoot Issues with Your Gateways (p. 297) for possible
solutions.
Next Step
You have completed the download, deployment, and activation steps common to all gateways. The
remaining setup steps are gateway-specific. To continue the setup process, choose one of the following
options:
• Step 2: Configure Local Storage and Alarms (Gateway-Cached and Gateway-Stored) (p. 72)
• Step 2: Configure Local Storage and Alarms (Gateway-VTL) (p. 104)
Topics
• Step 1: Choose A Gateway Configuration (p. 60)
• Step 2: Deploy and Activate a Gateway on Amazon EC2 (p. 61)
1. In the Setup and Activate Gateway on Amazon EC2 wizard's Select Gateway Type section,
choose the gateway type you want to activate.
Note
You can only create gateway-cached volumes or a gateway-VTL on an Amazon EC2
instance. For information about gateway types, see How AWS Storage Gateway Works
(Architecture) (p. 2).
2. In the Setup and Activate Gateway on Amazon EC2 wizard, click Launch Gateway AMI in step
1. Doing this opens the AWS Marketplace page in a new browser tab.
Next Step
Important
Regardless of how you access the AMI, we strongly recommend that you choose the Manual
Launch option in AWS Marketplace to launch your instance.You can find the steps for launching
this way in the following procedure. If you use the 1-Click Launch functionality to launch an
instance, you need to add Amazon EBS volumes to your instance as a separate step after the
instance is launched. For more information, .
1. In the Setup and Activate Gateway on Amazon EC2 wizard, choose your gateway type, and then
click Launch Gateway AMI to open the AWS Marketplace page for the AMI in your web browser.
On that page, click Continue.
2. On the Launch on EC2: page for the AMI, select the Manual Launch tab.
3. If this is your first time using the AWS Storage Gateway AMI, accept the terms of service by clicking
Accept Terms; otherwise, skip to the next step.
Keep the browser page open. Within a few moments, a subscription confirmation email is sent to the
email address of the account with which you logged in to AWS Marketplace.
4. In the Region list, select the AWS region you want to launch the instance in by clicking the Launch
with EC2 Console link next to the region name. Note that gateway-VTL AMIs are not available in
all regions.
Now the wizard directs you to the Amazon EC2 console for the next step in deploying the AMI.
1. On the Choose an Instance Type page, filter the instances by All instances and All generations
to show the available instance types, and then choose an instance. For this exercise, you can choose
the m3.xlarge instance type.
Note
AWS Storage Gateway only supports the m3, i2, c3, c4, r3, d2, and m4 instance types.
The instance size must be at least xlarge. For more information, go to AWS Storage Gateway
in AWS Marketplace.
2. Click Next: Configure Instance Details at the bottom of the page.
1. On the Configure Instance Details page, you have several configuration options for the instance,
including how many instances you want to launch from the AMI and whether you want to launch it
in EC2-Classic or in VPC. If you are creating a gateway for testing purposes, you can keep the default
values and go to the next step.
Note
If your AWS account is a default VPC account, the Network drop-down list has a default
VPC subnet setting, so that your gateway launches into a default VPC. In that case, you do
not have the option to launch into EC2-Classic. If you have an EC2-Classic account, you
can create a VPC for your account and launch the instance into the VPC. For information
about how to create a VPC, go to Getting Started with Amazon VPC in the Amazon VPC
Getting Started Guide.
The Amazon EC2 AMI launches with one root storage volume and a 10GiB EBS volume that is used as
a swap disk. You must add additional storage volumes for the gateway to use as cache storage and an
upload buffer. For more information, see Volume Gateway Architecture (Gateway-Cached and
Gateway-Stored) (p. 2).
Important
Do not delete any of the existing EBS volumes.
1. Click Add New Volume to add additional EBS or instance store volumes.
2. In the Type column, select EBS or Instance Store. The default is EBS.
Note
Instance store volumes are ephemeral—that is, the data on these volumes does not persist
when you stop and start or terminate the Amazon EC2 instance. For more information about
instance store volumes, go to Amazon EC2 Instance Store in the Amazon EC2 User Guide.
3. In the Size(GiB) column, enter the size of the volume. If you are creating this gateway as an example
setup, you can enter 10 GiB for an upload buffer, and 10 GiB for cache storage. Otherwise, you must
size your volumes for a production workload. For more information about sizing these two storage
types, see Managing the Upload Buffer (p. 238).
The size of the instance store you can add depends on the Amazon EC2 instance type. For more
information, see the Instance Types section in Amazon EC2 Instance Store in the Amazon EC2 User
Guide.
4. Repeat steps 1 through 3 to add another EBS or instance store volume. After this step, you should
have a total of four volumes—the root volume, the 10GiB swap disk, and the two volumes you just
added.
5. Click Next: Tag Instance.
1. On the Tag Instance page, define a tag with a friendly name for your instance (for example,
Name=MyGatewayVTLOnEC2). This tag then appears in the Amazon EC2 console where all your
Amazon EC2 instances appear.
The security group must allow port 80 traffic, at least, for activation to occur. To allow connections to
iSCSI storage targets of the gateway, you will need also to allow port 3260 traffic. Before launching your
instance, you might want to check your existing security groups or create a new security group for your
gateway instance. For more information about the security group requirements, see Configuring Security
Groups for Your Amazon EC2 Gateway Instance (p. 292).
We recommend that the gateway’s security group only allow traffic on port 3260 to a specific host (the
iSCSI initiator) or to a security group to which the initiator belongs.
• On the Configure Security Group page, add the following rules. If you are creating a gateway for
testing, you can create a new security group, assign a group name, and add these rules.
Caution
If you specify Anywhere (0.0.0.0/0) in Source, you enable all IP addresses to access
your instance using Secure Shell (SSH). Doing this is acceptable for a short time in a test
environment, but it is unsafe for production environments. In production, authorize only a
specific IP address or range of addresses to access your instance.
3. In the Launch Status, note the instance ID and click View Instances to open an Amazon EC2
console.
4. In the Amazon EC2 console, select the Amazon EC2 instance, click the Description tab at the
bottom, and then note the IP address. You will use this IP address to activate the gateway.
You can use the public or private IP address assigned to the gateway for activation. You must be
able to reach the IP address that you use from the browser from which you perform the activation.
In this walkthrough, you will use the public IP address to activate the gateway.
1. Now, go back to the AWS Storage Gateway console and provide the IP address in the Setup and
Activate Gateway on Amazon EC2 wizard. Make sure the gateway type you want to activate is
selected, and then click Proceed to Activation.
Note
Accessing Amazon EC2 Storage Gateway over a public Internet connection is not supported.
The elastic IP address of the Amazon EC2 instance cannot be used as the target address.
2. To complete the activation process, enter the information listed on the activation page. The activation
page you see depends on your gateway configuration.
• AWS Region determines where AWS stores your snapshots (for gateway-cached volumes) or
virtual tapes (for gateway-VTLs). You select the region in which to deploy your gateway in the
AWS Region box. You cannot change the region after the gateway is activated.
Note
AWS Storage Gateway is supported in the following regions.
• Gateway Time Zone specifies the time zone to use for your gateway.
• Gateway Name identifies your gateway.You use this name to manage your gateway in the console;
you can change it after the gateway is activated. This name must be unique to your account.
• Medium Changer Type specifies the type of medium changer to use for your backup software
(available for gateway-VTLs only).
Important
The type of medium changer you select depends on the backup software you plan to use.
The following table shows which medium changer to select for your backup software. This
list includes third-party backup software that has been tested and found to be compatible
with gateway-VTL.
Note
You must select the medium changer that is recommended for your backup
software. Other medium changers might not function properly. You can select a
different medium changer after the gateway is activated. For more information,
see Selecting a Medium Changer After Gateway Activation (p. 360).
• Tape Drive Type specifies the type of tape drive used by this gateway (available for gateway-VTLs
only).
The following screenshot shows the activation page for gateway-cached volumes or gateway-stored
volumes.
3. After you successfully activate the gateway, it appears in your AWS Storage Gateway console in
either the VTL Gateways or Volume Gateways section, depending on the type of gateway you
activated.
4. Click the gateway you just deployed. Depending on the type of gateway you activated, the Create
Volumes or Create Tapes button is displayed.
After your Amazon EC2 gateway is activated, you perform the following tasks to set up a fully functional
gateway:
Next Step
You have completed the deployment and activation steps that are necessary to activate an Amazon EC2
gateway regardless of the gateway type you deploy. The remaining setup steps required to set up
functioning gateway are gateway-specific. Click one of the links to continue with Step 2: of the setup
process.
• Step 2: Configure Local Storage and Alarms (Gateway-Cached and Gateway-Stored) (p. 72)
• Step 2: Configure Local Storage and Alarms (Gateway-VTL) (p. 104)
AWS Storage Gateway offers two volume-based storage solutions, gateway-cached volumes and
gateway-stored volumes.
The gateway-cached solution lets you create storage volumes and mount them as Internet Small Computer
System Interface (iSCSI) devices from your on-premises application servers. In this solution, the gateway
stores data you write to your gateway-cached volume in Amazon Simple Storage Service (Amazon S3)
and stores only a cache of frequently accessed data on your on-premises storage hardware.
The gateway-stored solution lets you store all your data locally in storage volumes on your on-premises
storage hardware. In this solution, the gateway periodically takes snapshots as incremental backups and
stores them in Amazon S3.
For more information about gateway-cached and gateway-stored volume architecture, see Volume
Gateway Architecture (Gateway-Cached and Gateway-Stored) (p. 2). For information about gateway
concepts and the storage solutions offered, see What Is AWS Storage Gateway? (p. 1)
The following sections provide information about setting up gateway-cached and gateway-stored volumes.
These sections are a continuation of the Getting Started with AWS Storage Gateway (p. 10) section, and
together they provide an end-to-end example setup. You can use the AWS Storage Gateway console to
set up and manage volumes, as shown in the following sections. You can also perform these tasks
programmatically using the AWS Storage Gateway API or the AWS SDK libraries. For more information
on using the AWS Storage Gateway API for this purpose, see API Reference for AWS Storage
Gateway (p. 332).
As you follow the steps in this section, you will use the Setup and Activate Gateway wizard in the AWS
Storage Gateway console. At several steps in the wizard, you will perform tasks outside of the console
and then return. If your session times out or the browser closes, you can return to the console.
Topics
• Related Topics (p. 72)
• Step 1: Before You Begin (p. 72)
• Step 2: Configure Local Storage and Alarms (Gateway-Cached and Gateway-Stored) (p. 72)
Related Topics
Getting Started with AWS Storage Gateway (p. 10)
1. Sign up for an AWS account. To use AWS Storage Gateway, you need an AWS account.
2. Deploy and activate a gateway. Steps to deploy and activate a gateway are the same regardless of
the type of storage solution you deploy.
You can find instructions for deploying and activating a gateway in the Getting Started section that is
common to all gateways, Getting Started with AWS Storage Gateway (p. 10). Before going on, you must
first complete these steps. When you have done so, continue to the next step.
Next Step
Step 2: Configure Local Storage and Alarms (Gateway-Cached and Gateway-Stored) (p. 72)
• For gateway-cached volumes, you will configure one disk for an upload buffer and the other for cache
storage.
• For gateway-stored volumes, you will configure one disk for an upload buffer and allocate the rest of
the storage for your application data.
If activation is not successful, see Troubleshoot Issues with Your Gateways (p. 297) for possible solutions.
When you click Create Volumes, the wizard walks you through how to configure local storage, optionally
create alarms, and create volumes for your gateway.
Note
When creating volumes for a gateway for the first time, you must first configure local storage for
the gateway.
Next Step
The steps you follow to configure local storage depends on the gateway type you activated. Click one of
the following links:
a. Of the two disks you provisioned, select one as the upload buffer and the other as cache storage,
as shown in the following screenshot.
b. Click Next.
Optionally, now you can create alarms to monitor the storage use of the two disks you created.
1. In the page for the upload buffer alarm, configure the alarms to notify you about upload buffer use.
a. Using the two drop-down lists, select utilization percentages to set two upload buffer alarms.
For example, you can set the first threshold (the lower percentage value) to a percentage use
of the upload buffer that, if exceeded, you want to be warned about. You can set the second
threshold (the higher percentage value) to a percentage use of the upload buffer that, if exceeded,
is cause for action. The action might be adding more upload buffer space.
After you complete this step, you can go to the CloudWatch console at any time and change
the alarm thresholds.
b. Type an email address to which alarm notifications should be sent.
c. Click Continue.
Two alarms are created. For example, if you use the gateway name MyNewGatewayCached,
the alarms created are MyNewGatewayCached-UploadBufferUtilization-Alarm1 and
MyNewGatewayCached-UploadBufferUtilization-Alarm2.
d. Check the email address that you provided for a subscription confirmation email, and follow the
instructions in that email to confirm your subscription to the related Amazon Simple Notification
Service (Amazon SNS) topic. After you have confirmed your subscription, you will receive an
email when either threshold you specified is exceeded.
For example, if you use the gateway name MyNewGatewayCached, the alarms created are
MyNewGatewayCached-CacheUtilization-Alarm1 and
MyNewGatewayCached-CacheUtilization-Alarm2.
4. Click Continue to create the alarms.
Next Step
2. In the Disk drop-down list, select the disk you want to use to store application data.
3. In the iSCSI Target Name text box, type a name for your volume, and then click Create Volume.
4. Click Configure Local Upload Buffer, at lower right.
5. Click the check box next to the remaining disk to allocate the disk as the upload buffer, and then
click Next.
This page lists all available disks on your virtual machine (VM). Earlier, you added two virtual disks
to the VM and configured one of the disks as a storage volume. Therefore, the page should show
one available disk. Select this disk to allocate as the upload buffer. You can extend the upload buffer
later without disrupting iSCSI input/output.
6. In the confirmation page, select the check box and click Confirm.
1. In the Upload Buffer Alarms page, configure alarms for your upload buffer.
a. Using the two drop-down lists, select utilization percentages to set two upload buffer alarms.
For example, you can set the first threshold (the lower percentage value) to a percentage use
of the upload buffer that, if exceeded, you want to be warned about. You can set the second
threshold to a percentage use of the upload buffer that, if exceeded, is cause for action. The
action might be adding more upload buffer space.
After you complete this step, you can go to the CloudWatch console at any time and change
the alarm thresholds.
b. Type an email address to which alarm notifications should be sent.
c. Click Continue.
Two alarms are created. For example, if you use the gateway name MyNewGateway, the alarms
created are MyNewGateway-UploadBufferUtilization-Alarm1 and
MyNewGateway-UploadBufferUtilization-Alarm2.
d. Check the email address that you provided for a subscription confirmation email, and follow the
instructions in that email to confirm your subscription to the Amazon Simple Notification Service
(Amazon SNS). After you have confirmed your subscription, you will receive an email when
either threshold you specified is exceeded.
For more detailed information about creating upload buffer alarms, see Monitoring the Upload
Buffer (p. 225).
2. In the Configure iSCSI Initiators page, click Close.
Next Step
Next Step
Depending on the gateway configuration you activated, click one of the following links:
Topics
• Create a Volume in Amazon S3 (p. 80)
• Configure CHAP Authentication for Your Volumes (p. 82)
The following architectural overview diagram shows the part of the gateway-cached setup that you are
creating.
1. In the Configure Your Activated Gateway dialog box, create an iSCSI storage volume in Amazon
S3.
a. For Capacity, specify the appropriate capacity to hold the data you plan to store in AWS. If you
are creating the gateway as an example setup, you can specify 50 GB. The maximum size you
can specify is 32 TB.
Note
If you plan to use these volumes as a snapshots in EBS then the size of the volumes
must not be larger than 16 TB.
b. Type a name in the iSCSI Target Name box.
The target name can contain lowercase letters, numbers, periods (.), and hyphens (-).This target
name appears as the iSCSI Target Node name in the Targets tab of the iSCSI Microsoft
Initiator UI after discovery. For example, the name target1 appears as
iqn.1007-05.com.amazon:target1. Ensure that the target name is globally unique within
your storage area network (SAN).
For this exercise, you can use myvolume as the target name.
c. Leave the Based on Snapshot ID box empty.
If you want to restore an existing Amazon EBS snapshot or a gateway snapshot on the storage
volume that you are creating, you must specify the snapshot ID. The gateway downloads your
existing snapshot data to the storage volume. For more information, see Restoring a Snapshot
to a Storage Volume (p. 212).
d. Verify that the Host IP setting is the IP address of your gateway, and then click Create Cached
Volume.
In the Configure CHAP Authentication dialog box, you provide information so that you can configure
CHAP for your volumes.
To configure CHAP
1. In the Configure CHAP Authentication dialog box, click the Enabled check box.
2. In the Initiator Name box, type the name of your initiator.
3. In the Secret Used to Authenticate Initiator box, type the secret phrase you used to authenticate
your iSCSI initiator.
4. In the Secret Used to Authenticate Target (Mutual CHAP) box, type the secret phrase used to
authenticate your target for mutual CHAP.
5. Click Save to save these values.
For more details on setting up CHAP authentication, see Configuring CHAP Authentication for Your
iSCSI Targets (p. 152).
Next Step
configure CHAP authentication for your volumes.Your on-premises applications write data to this storage
volume and store the data locally. The gateway periodically takes snapshots (incremental backups) and
uploads them to Amazon S3.
Topics
• Create a Storage Volume (p. 83)
• Configure CHAP Authentication for Your Volumes (p. 84)
The following architectural overview diagram shows the part of the gateway-stored setup that you are
creating.
• In the Create Storage Volume wizard, provide the storage volume information.
a. In the Disk drop-down list, select the 150 GiB virtual disk on your VM.
In Step 2.3.1: Decide the Amount of Local Disk Storage (p. 26), you added the required minimum
150 GiB virtual disk that will be used as upload buffer. This drop-down list shows the virtual disks
that you added to the gateway VM. Select the disk on which you plan to store data.
For information about how to allocate local storage, see Provision Local Disk Storage for the
Gateway VM
b. Keep the Preserve existing data check box unchecked.
Caution
Make sure that you don't have any existing data on the virtual disk. Any existing data
on the disk is lost.
c. Type a name in the iSCSI Target Name box.
The target name can contain lowercase letters, numbers, periods (.), and hyphens (-).This target
name appears as the iSCSI Target Node name in the Targets tab of the iSCSI Microsoft
Initiator UI after discovery. For example, the name target1 appears as
iqn.1007-05.com.amazon:target1. Ensure that the target name is globally unique within
your SAN.
d. Leave the Based on Snapshot ID box empty.
If you want to restore an existing Amazon EBS snapshot or a gateway snapshot on the storage
volume that you are creating, you must specify the snapshot ID. The gateway downloads your
existing snapshot data to the storage volume. For more information, see Restoring a Snapshot
to a Storage Volume (p. 212).
e. Verify that the Host IP setting is the IP address of your gateway, and then click Create Volume.
In the Configure CHAP Authentication dialog box, you provide information so that you can configure
CHAP for your volumes.
To configure CHAP
1. In the Configure CHAP Authentication dialog box, click the Enabled check box.
2. In the Initiator Name box, type the name of your initiator.
3. In the Secret Used to Authenticate Initiator box, type the secret phrase you used to authenticate
your iSCSI initiator.
4. In the Secret Used to Authenticate Target (Mutual CHAP) box, type the secret phrase used to
authenticate your target for mutual CHAP.
5. Click Save to save these values.
For more details on setting up CHAP authentication, see Configuring CHAP Authentication for Your
iSCSI Targets (p. 152).
Next Step
1. On the Start menu of your Windows client computer, type iscsicpl.exe in the Search Programs
and files box, locate the iSCSI initiator program and then run it.
Note
You must have administrator rights on the client computer to run the iSCSI initiator.
2. If prompted, click Yes to start the Microsoft iSCSI initiator service.
3. In the iSCSI Initiator Properties dialog box, click the Discovery tab, and then click the Discovery
Portal button.
4. In the IP address or DNS name text box of the Discover Target Portal dialog box, type the IP
address of your iSCSI target, and then click OK. You can obtain the IP address of your gateway in
the Gateway tab on the AWS Storage Gateway console. If you deployed your gateway on an Amazon
EC2 instance, you can obtain the public IP address or public DNS in the Description tab on the
Amazon EC2 console.
The IP address now appears in the list of Target portals in the Discovery tab.
5. Connect the new target portal to the storage volume target on the gateway:
The new target portal is shown with an inactive status. Note that the target name shown should
be the same as the name you specified for your storage volume in step 1.
If the target name is not populated already, type the name of the target as shown in step 1 in
the Connect to Target dialog box, select the check box next to Add this connection to the
list of Favorite Targets, and then click OK.
c. In the Targets tab, ensure that the target Status has the value Connected indicating the target
is connected, and then click OK.
You can now initialize and format this storage volume for Windows so you can begin saving data on it.
You do this by using the Windows Disk Management tool.
Note
Although it is not required for this exercise, we highly recommend that you customize your iSCSI
settings for a real-world application as discussed in the topic Customizing Your Windows iSCSI
Settings (p. 147).
1. In the Start menu, type diskmgmt.msc to open the Disk Management console.
2. In the Initialize Disk dialog box, select MBR (Master Boot Record) as the partition style, and then
click OK. When selecting the partition style, you should take into account the type of volume you are
connecting to—gateway-cached or gateway-stored—as shown in the following table.
MBR (Master Boot • If your gateway is a gateway-stored volume and the storage volume is
Record) limited to 1 TiB in size.
• If your gateway is a gateway-cached volume and the storage volume is
less than 2 TiB in size.
a. If the disk is offline, you must bring it online before you can initialize it. After the disk is initialized,
you can format it as a simple volume. All the available volumes are displayed in the disk
management console. In the following example, Disk 1 is the storage volume. Notice that when
you select the new volume, it displays hatch lines indicating that it is selected.
Important
Be careful not to format the wrong disk. Check to ensure that the disk you are formatting
matches the size of the local disk you allocated to the gateway VM and that it has a
status of Unallocated.
e. In the Assign Drive Letter or Path dialog box, keep the default values, and then click Next.
f. In the Format Partition dialog box, type a label in the Volume label box, and ensure that
Perform a quick format is selected. Click Next.
Caution
Selecting Perform a quick format is highly recommended for gateway-cached volumes
because it results in less initialization I/O, smaller initial snapshot size, and the fastest
time to a usable volume. It also avoids gateway-cached volume usage that comes from
the full format process and not from application data activity.
Next Step
Next Step
Depending on the type of gateway you activated, click one of the following links.
1. On your Windows computer, copy some data to your mapped storage volume.
The amount of data copied doesn't matter for this demonstration. A small file is enough to demonstrate
the restore process.
2. In the Navigation pane of the AWS Storage Gateway console, select the gateway.
3. In the Volumes tab, select the storage volume created for the gateway.
This gateway should have only one storage volume. Selecting the volume displays its properties.
4. Click the Create Snapshot button to create a snapshot of the volume.
Depending on the amount of data on the disk and the upload bandwidth, it might take a few seconds
to complete the snapshot. Note the volume ID for the volume from which you create a snapshot. You
will use the ID to find the snapshot.
6. In the Navigation pane, click Snapshots, and find the snapshot that you just created.
You can use the Started on column value and the volume ID you noted earlier to confirm the
snapshot's source. Note that the Started on time is UTC time.
The Status of your snapshot might be pending. In this case, you must wait for the snapshot Status
to change to completed before restoring the snapshot.
7. Copy the snapshot ID from the Snapshot ID list so you can enter it in a subsequent step when you
create a storage volume based on the snapshot.
1. In the AWS Storage Gateway console, click the name of gateway in the navigation pane.
2. Click the Volumes tab, and then click Create New Volume.
3. In the Create Storage Volume dialog box, enter the following information.
a. In the Capacity text box, enter the same capacity as the original volume from which you took
the snapshot.
b. In the iSCSI Target Name box, type a name for your iSCSI target—for example,
myvolumerestored.
The target name can contain lowercase letters, numbers, periods (.), and hyphens (-).This target
name appears as the iSCSI Target Node name in the Targets tab of the iSCSI Microsoft
Initiator GUI after discovery. For example, the name target1 appears as
iqn.1007-05.com.amazon:target1. Ensure that the target name is globally unique within
your SAN.
c. In the Based on Snapshot ID field, enter the snapshot ID.
d. Click Create Cached Volume.
Doing this creates a storage volume based on your snapshot. The volume details appear in the
AWS Storage Gateway console.
a. On the Start menu of your Windows client computer, click Run, type iscsicpl.exe, and then
click OK to run the iSCSI initiator program.
b. In the iSCSI Initiator Properties dialog box, click the Targets tab. If the new target does not
appear in the Discovered Targets pane, click Refresh.
You should see both the original target and the new target. The new target will have a status of
Inactive.
a. If the Disk Management console is not already open, on the Start menu of your Windows client
computer, click Run, type diskmgmt.msc, and then click OK to open the console.
b. Right-click the restored volume and select Online. Doing this brings the volume online and
assigns it a different drive letter.
6. Open the restored volume and verify that the data you saved earlier is there.
Next Step
Note
Restoring data from Amazon EBS volumes that are encrypted is not supported.
1. On your Windows computer, copy some data to your mapped storage volume.
The amount of data copied doesn't matter for this demonstration. A small file is enough to demonstrate
the restore process.
2. In the AWS Storage Gateway console, select the gateway in the navigation pane.
3. In the Volumes tab, select the storage volume created for the gateway.
This gateway should have only one storage volume. Selecting the volume displays its properties.
4. Click the Create Snapshot button to create a snapshot of the volume.
Depending on the amount of data on the disk and the upload bandwidth, it might take a few seconds
to complete the snapshot. Note the volume ID from which you create a snapshot. You will use the
ID to find the snapshot.
6. In the navigation pane, click Snapshots, and find the snapshot that you just created.
You can use the Started on column value and the volume ID you noted earlier to confirm the
snapshot's source. Note the Started on time is UTC time.
The Status of your snapshot might be pending. In this case, you must wait for the snapshot Status
to change to completed before restoring the snapshot.
7. Copy the snapshot ID from the Snapshot ID list so you can enter it in a subsequent step when you
create a storage volume based on the snapshot.
1. Add another virtual disk to your VM. This disk will become a new storage volume, on which you will
restore the snapshot. Because the original storage volume was 2 GiB in size, create a new virtual
disk of the same size. For instructions, see Step 2.3.2: Provision Local Disk Storage (p. 27) in the
Getting Started section.
2. In the AWS Storage Gateway console, click the name of the gateway in the navigation pane.
3. Click the Volumes tab, and then click Create New Volume.
4. In the Create Storage Volume dialog box, enter the following information.
a. In the Disk drop-down list, select the virtual disk that you added in the preceding step.
b. In the iSCSI Target Name box, enter a name for your iSCSI target—for example,
myvolumerestored.
The target name can contain lowercase letters, numbers, periods (.), and hyphens (-).This target
name appears as the iSCSI Target Node name in the Targets tab of the iSCSI Microsoft
Initiator GUI after discovery. For example, the name target1 appears as
iqn.1007-05.com.amazon:target1. Ensure that the target name is globally unique within
your SAN.
c. In the Based on Snapshot ID box, type the snapshot ID.
d. Click Create Volume.
Doing this creates a storage volume based on your snapshot.The storage volume details appear
in the AWS Storage Gateway console.
a. On the Start menu of your Windows client computer, click Run, type iscsicpl.exe, and then
click OK to run the iSCSI initiator program.
b. In the iSCSI Initiator Properties dialog box, click the Targets tab. If the new target does not
appear in the Discovered Targets pane, click Refresh.
You should see both the original target and the new target. The new target will have a status of
Inactive.
a. If the Disk Management console is not already open, on the Start menu of your Windows client
computer, click Run, type diskmgmt.msc, and then click OK to open the console.
b. Right-click the restored volume, and select Online. Doing this brings the volume online and
assigns it a different drive letter.
7. Open the restored volume and verify that the data you saved earlier is there.
Next Step
If you plan to continue using your gateway, see additional information in Where Do I Go from Here? (p. 100)
1. Delete any snapshots from the gateway. For instructions, see Deleting a Snapshot (p. 196).
2. You can keep the gateway if you plan to use it. Otherwise, delete the gateway.
a. After deleting all snapshots, delete the gateway. For instructions, see
b. Delete the AWS Storage Gateway VM from your on-premises host.
Next Step
• If you plan on continuing to use your gateway, you should read about sizing the upload buffer more
appropriately for real-world workloads. For more information, see Sizing Your Gateway's Storage for
Real-World Workloads (p. 100).
• If you don't plan on continuing to use your gateway, consider deleting the gateway to avoid incurring
any charges. For more information, see Step 6: Clean Up After the Example Exercise (p. 99).
Other sections of this guide include information about how to do the following:
• Learn more about storage volumes and how to manage them (see Managing Your Activated
Gateway (p. 144)).
• Troubleshoot gateway problems (see Troubleshoot Issues with Your Gateways (p. 297)).
• Optimize your gateway (see Optimizing Gateway Performance (p. 250)).
• Understand Storage Gateway metrics and how you can monitor how your gateway performs Monitoring
Your Gateway (p. 216)).
• Connect to the gateway's iSCSI targets to store data (see Connecting to Volumes on Your Volume
Gateway (p. 145)).
This topic shows how to do both of these tasks. If you activated a gateway for gateway-cached volumes,
you also need to size your cache storage for real-world workloads.
To size your upload buffer and cache storage for a gateway-cached setup
• Use the formula shown in Managing the Upload Buffer (p. 238) for sizing the upload buffer. We strongly
recommend that you allocate at least 150 GiB for the upload buffer. If the upload buffer formula yields
a value less than 150 GiB, use 150 GiB as your allocated upload buffer.
The upload buffer formula takes into account the difference between throughput from your application
to your gateway and throughput from your gateway to AWS, multiplied by how long you expect to
write data. For example, assume that your applications write text data to your gateway at a rate of
40 MB per second for 12 hours a day and your network throughput is 12 MB per second. Assuming
a compression factor of 2:1 for the text data, the formula specifies that you need to allocate
approximately 675 GiB of upload buffer space.
• Use the formula discussed in Managing the Upload Buffer (p. 238). We strongly recommend that you
allocate at least 150 GiB for your upload buffer. If the upload buffer formula yields a value less than
150 GiB, use 150 GiB as your allocated upload buffer.
The upload buffer formula takes into account the difference between throughput from your application
to your gateway and throughput from your gateway to AWS, multiplied by how long you expect to
write data. For example, assume that your applications write text data to your gateway at a rate of
40 MB per second for 12 hours a day and your network throughput is 12 MB per second. Assuming
a compression factor of 2:1 for the text data, the formula specifies that you need to allocate
approximately 675 GiB of upload buffer space.
• In the Gateway tab in the AWS Storage Gateway console, find the Upload Buffer Used field.
2. Set one or more alarms to notify you about upload buffer use.
We highly recommend that you create one or more upload buffer alarms in the CloudWatch console.
For example, you can set an alarm for a level of use you want to be warned about and an alarm for
a level of use that, if exceeded, is cause for action. The action might be adding more upload buffer
space. For more information, see To set an upper threshold alarm for a gateway's upload buffer (p. 226).
Gateway–virtual tape library (VTL) offers a durable, cost-effective solution to offline data archiving. The
VTL interface lets you use your existing tape-based backup infrastructure to store data on virtual tape
cartridges, which you create on your gateway-VTL. Each gateway-VTL is preconfigured with a media
changer and tape drives, which are available to your existing client backup applications as Internet Small
Computer System Interface (iSCSI) devices. You add virtual tape cartridges as you need to archive your
data.
For more information about the gateway-VTL architecture, see Gateway–Virtual Tape Library
(Gateway-VTL) Architecture (p. 5). For information about gateway concepts and storage solutions
offered, see What Is AWS Storage Gateway? (p. 1)
The following sections provide information about setting up a gateway-VTL. These section is a continuation
of the Getting Started with AWS Storage Gateway (p. 10) section, and provides an end-to-end example
setup. You can use the AWS Storage Gateway console to perform these tasks, or you can perform these
tasks programmatically using the AWS Storage Gateway API. For more information on using this API,
see API Reference for AWS Storage Gateway (p. 332) or the AWS SDK libraries.
As you follow the steps in this section, you will use the Setup and Activate Gateway wizard in the AWS
Storage Gateway console. At several steps in the wizard, you will perform tasks outside of the console
and then return. If your session times out or the browser closes, you can return to the console.
Topics
• Related Topics (p. 103)
• Step 1: Before You Begin (p. 104)
• Step 2: Configure Local Storage and Alarms (Gateway-VTL) (p. 104)
• Step 3: Create Virtual Tapes Using the AWS Storage Gateway Console (p. 106)
• Step 4: Connect Your Gateway-VTL Devices to Your Windows Client (p. 108)
• Step 5: Test the Gateway-VTL Setup (p. 112)
• Step 6: Clean Up After the Example Exercise (p. 142)
• Where Do I Go from Here? (p. 143)
Related Topics
Getting Started with AWS Storage Gateway (p. 10)
1. Sign up for an AWS account. To use AWS Storage Gateway, you need an AWS account.
2. Deploy and activate a gateway. Steps to deploy and activate gateway are the same regardless of the
type of storage solution you are deploying.
You can find instructions for deploying and activating a gateway in the Getting Started section that is
common to all gateways, Getting Started with AWS Storage Gateway (p. 10). Before going on, you must
first complete these steps. When you have done so, continue to the next step.
Next Step
In a gateway-VTL setup, after your gateway is activated, the Create Tapes button is displayed. If activation
is not successful, see Troubleshoot Issues with Your Gateways (p. 297) for possible solutions.
When you click Create Tapes, the wizard walks you through how to configure local storage, optionally
create alarms, and create virtual tapes for your gateway.
Note
When creating virtual tapes for a gateway for the first time, you must first configure local storage
for your gateway.
1. Click Create Tapes to start the Configure Your Activated Gateway wizard.
2. In the Configure Your Activated Gateway wizard, configure local working storage.
a. Of the two disks you provisioned, select one as the upload buffer and the other as cache storage,
as shown in the preceding screenshot.
b. Click Next.
Optionally, you can create alarms to monitor the storage use of the two disks you created.
To configure alarms
1. In the upload buffer alarm page, configure the alarm for upload buffer use.
a. Using the two drop-down lists, select utilization percentages to set two upload buffer alarms.
For example, you can set the first threshold (the lower percentage value) to a percentage use
of the upload buffer that, if exceeded, you want to be warned about. You can set the second
threshold (the higher percentage value) to a percentage use of the upload buffer that, if exceeded,
is cause for action. The action might be adding more upload buffer space.
After you complete this step, you can go to the CloudWatch console at any time and change
the alarm thresholds.
b. Type an email address to which alarm notifications should be sent.
c. Click Continue.
Two alarms are created. You can name the alarms—for example,
MyGatewayBufferUtilizationAlarm.
d. Check the email address you provided for a subscription confirmation email, and follow the
instructions in that email to confirm your subscription to the related Amazon Simple Notification
Service (Amazon SNS) topic. After you have confirmed your subscription, you will receive an
email when either threshold you specified is exceeded.
Follow the instructions in step 1 of the To configure alarms (p. 105) procedure to configure the alarms.
Next Step
Step 3: Create Virtual Tapes Using the AWS Storage Gateway Console (p. 106)
1. In the Number of Tapes text box, type the number of tapes you want to create. For this exercise,
you can create three tapes. You can create a maximum of 1500 tapes per gateway. However, you
can create a maximum of 10 virtual tapes at a time. For more information, see AWS Storage Gateway
Limits (p. 362).
2. In the Capacity text box, select the size of virtual tapes you want to create. For this exercise, you
can enter 100 GiB. For information about capacity limits, see AWS Storage Gateway Limits (p. 362).
3. In the Barcode Prefix text box, type the prefix you want to prepend to the barcode of your virtual
tapes. For this exercise, you can accept the default.
Note
Virtual tapes are uniquely identified by a barcode. You can add a prefix to the barcode. The
prefix is optional, but you can use it for your virtual tapes. The prefix must be uppercase
letters (A–Z) and must be 1 to 4 characters long.
4. Click Create Tapes.
The confirmation page shows the iSCSI targets on your gateway. You can view this information in
the AWS Storage Gateway console at any time by selecting your gateway and navigating to the VTL
Devices tab.
The following screenshot shows the confirmation page for the devices that were created for your
gateway.
The virtual tapes you have created appear in the AWS Storage Gateway console. The console shows
the barcode, capacity, and status of the virtual tapes. The status of the virtual tapes is initially set to
CREATING when the virtual tapes are being created. After the tapes are created, their status changes
to AVAILABLE. For more information, see Managing Tapes in Your VTL (p. 176).
Next Step
Step 4: Connect Your Gateway-VTL Devices to Your Windows Client (p. 108)
1. On the Start menu of your Windows client computer, type iscsicpl.exe in the Search Programs
and files box, locate the iSCSI initiator program and then run it.
Note
You must have administrator rights on the client computer to run the iSCSI initiator.
2. If prompted, click Yes to start the Microsoft iSCSI initiator service.
3. In the iSCSI Initiator Properties dialog box, click the Discovery tab, and then click the Discover
Portal button.
4. In the IP address or DNS name box of the Discover Target Portal dialog box, type the IP address
of your gateway-VTL, and then click OK. You can obtain the IP address of your gateway in the
Gateway tab on the AWS Storage Gateway console. If you deployed your gateway on an Amazon
EC2 instance, you can obtain the public IP address or public DNS in the Description tab on the
Amazon EC2 console.
5. Select the Targets tab and click Refresh. All 10 tape drives and the medium changer appear in the
Discovered targets box. The status for the targets is Inactive.
6. Select the first device and click Connect. You connect the devices one at a time.
7. In the Connect to Target dialog box, click OK.
8. Repeat steps 6 and 7 for each of the devices to connect all of them, and then click OK in the iSCSI
Initiator Properties dialog box.
9. On a Windows client, the driver provider for the tape drive must be Microsoft. Use the following
procedure to verify the driver provider, and update the driver and provider if necessary.
3. In the Driver tab of the Device Properties dialog box, verify the Driver Provider is Microsoft.
3. In the Update Driver Software dialog box, click Let me pick from a list of device drivers
on my computer.
5. Click Close to close the Update Driver Software window, and verify that the Driver Provider
value is now set to Microsoft.
6. Repeat steps 9.2 through 9.5 to update all the tape drives.
Next Step
You can test your setup with one of the following types of compatible backup software:
• Testing Your Setup by Using Symantec NetBackup Version 7.x (p. 113).
• Testing Your Setup by Using Symantec Backup Exec (p. 127).
• Testing Your Setup by Using Microsoft System Center 2012 R2 Data Protection Manager (p. 131).
• Testing Your Setup by Using Veeam Backup & Replication (p. 134).
• Testing Your Setup by Using Dell NetVault Backup (p. 137).
• Testing Your Setup by Using EMC NetWorker (p. 140).
For more information about compatible backup software, see Compatible Third-Party Backup Software
for Gateway-VTL (p. 13).
In this topic, you can find out how to configure storage, write data to a tape, archive a tape in the VTS,
and restore the data.
For more information about compatible backup software, see Compatible Third-Party Backup Software
for Gateway-VTL (p. 13).
Topics
• Configuring NetBackup Storage Devices (p. 113)
• Backing Up Sample Data to a Tape on Your Gateway-VTL (p. 117)
• Archiving the Tape (p. 122)
• Retrieving the Archived Tape from the VTS Back to Your Gateway-VTL (p. 124)
• Restoring Data from the Tape (p. 125)
5. In the Scanning Hosts page, choose Next, and then choose Next. The NetBackup software finds
all 10 tape drives and the medium changer on your computer.
8. In the dialog box that appears, choose Yes to save the configuration on your computer.The NetBackup
software updates the device configuration.
9. When the update is completed, choose Next to make the devices available to the NetBackup software.
10. In the Finished! window, choose Finish.
1. In the NetBackup Administration Console, expand the Media and Device Management node, and
then expand the Devices node. Choose Drives to display all the tape drives.
2. In the Devices node, choose Robots to display all your medium changers. In the NetBackup software,
the medium changer is called a robot.
3. In the All Robots pane, open the context (right-click) menu for TLD(0) (that is, your robot), and then
choose Inventory Robot.
4. In the Robot Inventory window, verify that your host is selected from the Device-Host list located
in the Select robot category.
5. Verify that your robot is selected from the Robot list.
6. In the Robot Inventory window, select Update volume configuration, select Preview changes,
select Empty media access port prior to update, and then choose Start.
The process then inventories your medium changer and virtual tapes in the NetBackup Enterprise
Media Management (EMM) database. NetBackup stores media information, device configuration,
and tape status in the EMM.
7. In the Robot Inventory window, choose Yes once the inventory is complete. Choosing Yes here
updates the configuration and moves virtual tapes found in import/export slots to the virtual tape
library.
For example, the following screenshot shows three virtual tapes found in the import/export slots.
Now that you have connected your devices and made them available to your backup software, you are
ready to test your gateway. To test your gateway, you back up data onto the virtual tapes you created
and archive the tapes in the virtual tape shelf (VTS), which is backed by Amazon Glacier.
1. Expand the Robots node, and select the TLD(0) robot to display the virtual tapes this robot is aware
of.
Note that if you have previously connected a robot, your gateway-VTL robot might have a different
name.
2. From the list of virtual tapes, open the context (right-click) menu for the tape you want to add to the
volume pool, and choose Change to open the Change Volumes dialog box. The following screenshot
shows the Change Volumes dialog box.
You can verify that your volume pool contains the virtual tape that you just added by expanding the
Media node and choosing your volume pool.
The backup policy specifies what data to back up, when to back it up, and which volume pool to use.
The following screenshot shows the NetBackup console with Create a Policy selected.
6. In the Files window, choose Add, and then choose the folder icon.
7. In the Browse window, browse to the folder or files you want to back up, choose OK, and then choose
Next.
8. In the Backup Types window, accept the defaults, and then choose Next.
Note
If you want to initiate the backup yourself, select User Backup.
9. In the Frequency and Retention window, select the frequency and retention policy you want to
apply to the backup. For this exercise, you can accept all the defaults and choose Next.
10. In the Start window, select Off hours, and then choose Next. This selection specifies that your folder
should be backed up during off hours only.
The policy runs the backups according to the schedule. You can also perform a manual backup at any
time, which we will do in the next step.
1. On the navigation pane of the NetBackup console, expand the NetBackup Management node.
2. Expand the Policies node.
3. Open the context (right-click) menu for your policy, and choose Manual Backup.
4. In the Manual Backup window, select a schedule, select a client, and then choose OK.
5. In the Manual Backup Started dialog box that appears, choose OK.
6. On the navigation pane, choose Activity Monitor to view the status of your backup in the Job ID
column.
To find the barcode of the virtual tape where NetBackup wrote the file data during the backup, look in the
Job Details window as described in the following procedure. You will need this barcode in the procedure
in the next section, where you archive the tape to the virtual tape shelf (VTS).
1. In Activity Monitor, open the context (right-click) menu for the identifier of your backup job in the
Job ID column, and then choose Details.
2. In the Job Details window, choose the Detailed Status tab.
3. In the Status box, locate the media ID. For example, in the following screenshot, the media ID is
87A222. This ID helps you determine which tape you have written data to.
You have now successfully deployed a gateway-VTL, created virtual tapes, and backed up your data.
Next, you can archive the virtual tapes and retrieve them from the VTS.
1. In the NetBackup Administration console, expand the Media and Device Management node, and
expand the Media node.
2. Expand Robots and choose TLD(0).
3. Open the context (right-click) menu for the virtual tape you want to archive, and choose Eject Volume
From Robot.
4. In the Eject Volumes window, make sure the Media ID matches the virtual tape you want to eject,
and then choose Eject.
5. In the dialog box, choose Yes. The dialog box is shown following.
When the eject process is completed, the status of the tape in the Eject Volumes dialog box indicates
that the eject succeeded.
Note
It takes about 24 hours to retrieve a tape from the VTS to a gateway.
1. In the navigation pane of the AWS Storage Gateway console, choose Virtual Tape Shelf. The
console displays all virtual tapes that have been archived by all your gateways.
2. Select the virtual tape you want to retrieve, and choose Retrieve Tape.
Note
The status of the virtual tape you want to retrieve must be ARCHIVED.
3. In the Tape Barcode field of the Retrieve Tape wizard, verify that the barcode identifies the virtual
tape you want to retrieve.
4. For Gateway, choose the gateway you want to retrieve the archived tape to, and then choose
Proceed.
The status of the tape changes from ARCHIVED to RETRIEVING. After all the data is moved, the status
of the virtual tape in the VTS changes to RETRIEVED, and the tape appears in your gateway's VTL.
Note
Retrieved virtual tapes are read-only.
To restore data
1. Start the Backup, Archive, and Restore software, and run it as an administrator.
2. Choose the Select for Restore tab.
3. If you have previously backed up data, you will see backup icons in the NetBackup History pane.
In this example, there is only one backup icon.
4. Select the backup icon that represents the backup you want to restore.
5. In the All Folders pane, select the folder you want to restore, and then choose the Restore Marked
Files icon in the left pane. This icon is not labeled. The name appears when you rest your mouse
on the icon.
6. In the Restore Marked Files window, select the Restore everything to a different location
(maintaining existing structure) button. This selection avoids overwriting your original data.
7. For Destination, browse to the folder you want to restore the data to, and then choose Start Restore.
8. In the dialog box that appears, choose Yes to view the progress of the restore process.
In the View Status window, you can see the status of the restore process. If the restore succeeds,
the status changes to Successful.
Next Step
The procedure for using these versions of Backup Exec with AWS Storage Gateway–VTL is the same.
For detailed information about how to use Backup Exec, see the How to Create Secure Backups with
Backup Exec video on the Symantec website. For Symantec support information on hardware compatibility,
see the Software Compatibility Lists (SCL), Hardware Compatibility Lists (HCL), and Administrator Guides
for Backup Exec (all versions) on the Symantec website. For information about best practices, see Best
Practices for using Symantec Backup products (NetBackup, Backup Exec) with the Amazon Web Services
(AWS) Storage Gateway-VTL on the Symantec website.
Note
You can also use Symantec Backup Exec 2012 with AWS Storage Gateway–VTL. For information,
see Using Symantec Backup Exec 2012 to Test Your Setup (p. 383).
Using Symantec Backup Exec, you can configure storage, write data to a tape, archive a tape in the VTS,
and restore the data.
For more information about compatible backup software, see Compatible Third-Party Backup Software
for Gateway-VTL (p. 13).
Topics
• Configuring Storage in Backup Exec (p. 128)
• Importing a Tape in Backup Exec (p. 128)
• Writing Data to a Tape in Backup Exec (p. 130)
• Archiving a Tape Using Backup Exec (p. 130)
• Restoring Data from a Tape Archived in Backup Exec (p. 130)
• Disabling a Tape Drive in Backup Exec (p. 131)
To configure storage
1. Start the Backup Exec software, and then choose the yellow icon in top-left corner on the toolbar.
2. Choose Configuration and Settings, and then choose Backup Exec Services to open the Backup
Exec Service Manager.
3. Choose Restart All Services. Backup Exec then recognizes the VTL devices (that is, the medium
changer and tape drives). The restart process might take a few minutes.
Note
AWS Storage Gateway–VTL provides 10 tape drives. However, your Backup Exec license
agreement might require your backup software to work with fewer than 10 tape drives. In
that case, you must disable tape drives in the Backup Exec robotic library to leave only the
number of tape drives allowed by your license agreement enabled. For instructions, see
Disabling a Tape Drive in Backup Exec (p. 131).
4. After the restart is completed, close the Backup Exec Service Manager.
1. Choose the Storage tab, and then expand the Robotic library tree to display the VTL devices.
Important
Symantec Backup Exec software requires the AWS Gateway-VTL medium changer type.
If the medium changer type listed under Robotic library is not AWS Gateway-VTL, you
must change it before you configure storage in the backup software. For information about
how to select a different medium changer type, see Selecting a Medium Changer After
Gateway Activation (p. 360).
5. In the Action Alert: Media Intervention window, choose Respond OK to insert the media into the
slot.
1. Choose the Storage menu, choose Slots, open the context (right-click) menu for the slot you want
to export the tape from, choose Export media, and then choose Export media now.You can select
more than one slot and export multiple tapes in a single export operation.
2. In the Media Request pop-up window, choose View details, and then choose Respond OK in the
Alert: Media Intervention window.
In the AWS Storage Gateway console, you can verify the status of the tape you are archiving. It might
take some time to finish uploading data to AWS. During this time, the exported tape will be listed in
the gateway's VTL with the status IN TRANSIT TO VTS. When the upload is completed and the
archiving process begins, the status changes to ARCHIVING. When data archiving has completed,
the exported tape will no longer be listed in the VTL.
3. Choose your gateway, and then choose VTL Tape Cartridges and verify that the virtual tape is no
longer listed in your gateway.
4. On the Navigation pane of the AWS Storage Gateway console, choose Virtual Tape Shelf (VTS).
Verify that your archived tape is listed in the VTS and that the status is ARCHIVED.
1. Retrieve the archived tape from your VTS to a gateway-VTL. For instructions, see Retrieving the
Archived Tape from the VTS Back to Your Gateway-VTL (p. 124).
2. Use Backup Exec to restore the data. This process is the same as restoring data from physical tapes.
For instructions, see the Backup Exec Administrative Guide in the documentation section in the
Backup Exec software.
For more information about compatible backup software, see Compatible Third-Party Backup Software
for Gateway-VTL (p. 13).
Topics
• Configuring DPM to Recognize VTL Devices (p. 131)
• Importing a Tape into DPM (p. 132)
• Writing Data to a Tape in DPM (p. 133)
• Archiving a Tape by Using DPM (p. 133)
• Restoring Data from a Tape Archived in DPM (p. 134)
By default, the DPM server does not recognize gateway-VTL devices. To configure the server to work
with the gateway-VTL devices, you perform the following tasks:
1. Update the device drivers for the VTL devices to expose them to the DPM server.
2. Manually map the VTL devices to the DPM tape library.
• In Device Manager, update the driver for the medium changer. For instructions, see Updating the
Device Driver for Your Medium Changer (p. 361).
You use the DPMDriveMappingTool to map your VTL tape drives to the DPM tape library.
1. Create at least one tape for your gateway. For information on how to do this on the console, see
Step 3: Create Virtual Tapes Using the AWS Storage Gateway Console (p. 106).
2. Import the tape into the DPM library. For information on how to do this, see Importing a Tape into
DPM (p. 132).
3. If the DPMLA service is running, stop it by opening a command terminal and typing the following on
the command line.
1. On the DPM server, open the Management Console, choose Rescan, and then choose Refresh.
Doing this displays your medium changer and tape drives.
2. Open the context (right-click) menu for the media changer in the Library section, and then choose
Add tape (I/E port) to add a tape to the Slots list.
Note
The process of adding tapes can take several minutes to complete.
The tape label appears as Unknown, and the tape is not usable. For the tape to be usable, you must
identify it.
3. Open the context (right-click) menu for the tape you want to identify, and then choose Identify
unknown tape.
Note
The process of identifying tapes can take a few seconds or a few minutes.
When identification is complete, the tape label changes to Free. That is, the tape is free for data to
be written to it.
In the following screenshot, the tape in slot 2 has been identified and is free to use but the tape in
slot 3 is not.
1. Open the context (right-click) menu for the tape you want to archive, and then choose Remove tape
(I/E port).
2. In the dialog box that appears, choose Yes. Doing this ejects the tape from the medium changer's
storage slot and moves the tape into one of the gateway's I/E slots. When a tape is moved into the
gateway's I/E slot, it is immediately sent to the VTS for archiving.
3. On the AWS Storage Gateway console, choose your gateway, and then choose VTL Tape Cartridges
and verify the status of the virtual tape you are archiving.
The archiving process can take some time to complete. The initial status of the tape is shown as IN
TRANSIT TO VTS. When archiving starts, the status changes to ARCHIVING. When archiving is
completed, the tape is no longer listed in the VTL.
1. Retrieve the archived tape from your VTS to a gateway-VTL. For instructions, see Retrieving the
Archived Tape from the VTS Back to Your Gateway-VTL (p. 124).
2. Use the DPM backup software to restore the data. You do this by creating a recovery point, as you
do when restoring data from physical tapes. For instructions, see Recovering Client Computer Data
on the DPM website.
For more information about compatible backup software, see Compatible Third-Party Backup Software
for Gateway-VTL (p. 13).
Topics
• Configuring the Veeam Software to Work with VTL Devices (p. 134)
• Importing a Tape into the Veeam Software (p. 135)
• Backing Up Data to a Tape in the Veeam Software (p. 136)
• Archiving a Tape by Using the Veeam Software (p. 136)
• Restoring Data from a Tape Archived in the Veeam Software (p. 136)
1. In the Veeam software, choose Backup Infrastructure. When the gateway-VTL is connected, virtual
tapes will be listed in the Backup Infrastructure tab.
Note
Depending on the version of the Veeam Backup & Replication backup software you are
using, the user interface might differ somewhat from that shown in the screenshots in this
documentation.
2. Expand the Tape tree to see your tape drives and medium changer.
3. Expand the medium changer tree. If your tape drives are mapped to the medium changer, the drives
will appear under Drives. Otherwise, your tape library and tape drives appear as separate devices.
If the drives are not mapped automatically, follow the instructions on the Veeam website to map the
drives.
1. Open the context (right–click) menu for the medium changer, and choose Import to import the tapes
to the I/E slots.
2. Open the context (right–click) menu for the medium charger, and choose Inventory Library to identify
unrecognized tapes. When you load a new virtual tape into a tape drive for the first time, the tape is
not recognized by the Veeam backup application. To identify the unrecognized tape, you inventory
the tapes in the tape library.
1. You create a media pool and add the tape to the media pool.
2. You write data to the tape.
You create a media pool and write data to a virtual tape by using the same procedures you do with physical
tapes. For detailed information about how to back up data, see the Veeam documentation in the Veeam
Help Center.
1. Choose Backup Infrastructure, and choose the media pool that contains the tape you want to
archive.
2. Open the context (right–click) menu for the tape that you want to archive, and then choose Eject
Tape.
3. For Ejecting tape box, choose Close. The location of the tape changes from a tape drive to a slot.
4. Open the context (right–click) menu for the tape again, and then choose Export. The status of the
tape changes from Tape drive to Offline.
5. For Exporting tape, choose Close. The location of the tape changes from Slot to Offline.
6. On the AWS Storage Gateway console, choose your gateway, and then choose VTL Tape Cartridges
and verify the status of the virtual tape you are archiving.
The archiving process can take some time to complete. The initial status of the tape is shown as IN
TRANSIT TO VTS. When archiving starts, the status changes to ARCHIVING. When archiving is
completed, the tape is no longer listed in the VTL.
1. Retrieve the archived tape from your VTS to a gateway-VTL. For instructions, see Retrieving the
Archived Tape from the VTS Back to Your Gateway-VTL (p. 124).
2. Use the Veeam software to restore the data. You do this by creating a restoring a folder file, as you
do when restoring data from physical tapes. For instructions, see Restoring Data from Tape in the
Veeam Help Center.
For more information about compatible backup software, see Compatible Third-Party Backup Software
for Gateway-VTL (p. 13).
Topics
• Configuring the NetVault Backup Software to Work with VTL Devices (p. 137)
• Backing Up Data to a Tape in the NetVault Backup Software (p. 138)
• Archiving a Tape by Using the NetVault Backup Software (p. 139)
• Restoring Data from a Tape Archived in the NetVault Backup Software (p. 139)
By default, the NetVault Backup software does not automatically recognize gateway-VTL devices. You
must manually add the devices to expose them to the NetVault Backup software and then discover the
VTL devices.
4. On the next page, choose the client machine that is physically attached to the library and choose
Next to scan for devices.
5. If devices are found, they will be displayed. In this case, your medium changer is displayed in the
device box.
6. Select your medium changer and choose Next. Detailed information about the device is displayed
in the wizard.
7. On the Add Tapes to Bays page, select Scan For Devices, choose your client machine, and then
choose Next.
All your drives are displayed on the page. NetVault Backup displays the 10 bays to which you can
add your drives. The bays are displayed one at a time.
8. Choose the drive you want to add to the bay that is displayed, and then choose Next.
Important
When you add a drive to a bay, the drive and bay numbers must match. For example, if bay
1 is displayed, you must add drive 1. If a drive is not connected, leave its matching bay
empty.
9. When your client machine appears, choose it, and then choose Next. The client machine can appear
multiple times.
10. When the drives are displayed, repeat steps 7 through 9 to add all the drives to the bays.
11. In the Configuration tab, choose Manage devices and on the Manage Devices page, expand your
medium changer to see the devices you added.
1. In the NetVault Backup Configuration tab, choose and expand your medium changer to see your
tapes.
2. On the Slots row, choose the settings icon to open the Slots Browser for the medium changer.
3. In the slots, locate the tape you want to archive, choose it, and then choose Export.
1. Retrieve the archived tape from your VTS to a gateway-VTL. For instructions, see Retrieving the
Archived Tape from the VTS Back to Your Gateway-VTL (p. 124).
2. Use the NetVault Backup software to restore the data. You do this by creating a restoring a folder
file, as you do when restoring data from physical tapes. For instructions, see NetVault Backup 10.0.1
– Administration Guide (Creating a restore job) in the NetVault Backup documentation.
For detailed information about how to install and use the EMC NetWorker software, see the EMC NetWorker
Administration Guide.
For more information about compatible backup software, see Compatible Third-Party Backup Software
for Gateway-VTL (p. 13).
Topics
• Configuring the EMC NetWorker Software to Work with VTL Devices (p. 140)
• Enabling Import of WORM Tapes into EMC NetWorker (p. 141)
• Backing Up Data to a Tape in EMC NetWorker (p. 141)
• Archiving a Tape in EMC NetWorker (p. 142)
• Restoring Data from an Archived Tape in EMC NetWorker (p. 142)
EMC NetWorker doesn't automatically recognize gateway-VTL devices. To expose your VTL devices to
the NetWorker software and get the software to discover them, you manually configure the software.
Following, we assume that you have correctly installed the EMC NetWorker software and that you are
familiar with the EMC NetWorker Management Console. For more information about the EMC NetWorker
Management Console, see the NetWorker Management Console interface section of the EMC NetWorker
Administration Guide.
1. Start the EMC NetWorker Management Console application, choose Enterprise from the menu, and
then choose localhost from the left pane.
2. Open the context (right-click) menu for localhost, and then choose Launch Application.
3. Choose the Devices tab, open the context (right-click) menu for Libraries, and then choose Scan
for Devices.
4. In the Scan for Devices wizard, choose Start Scan, and then choose OK from the dialog box that
appears.
5. Expand the Libraries folder tree to see all your libraries. This process might take a few seconds to
load the devices into the library. In the example shown preceding, we have one library ([email protected]).
6. Open the context (right-click) menu for your library, and then choose Configure All Libraries.
7. In the Provide General Configuration Information box, choose the configuration settings you want,
and then choose Next.
8. In the Select Target Storage Nodes box, verify that a storage node is selected, and then choose
Start Configuration.
9. In the Start Configuration wizard, choose Finish.
10. Choose your library to see your tapes in the left pane and the corresponding empty volume slots list
in the right pane.
11. In the volume list, select the volumes you want to enable (selected volumes are highlighted), open
the context (right-click) menu for the selected volumes, and then choose Deposit. This action moves
the tape from the I/E slot into the volume slot.
12. In the dialog box that appears, choose Yes, and then in the Load the Cartridges into dialog box,
choose Yes.
13. If you don't have any more tapes to deposit, choose No or Ignore. Otherwise, choose Yes to deposit
additional tapes.
The virtual tapes are write once read many (WORM) tapes, but EMC NetWorker expects non-WORM
tapes. For EMC NetWorker to work with your virtual tapes, you must enable import of tapes into non-WORM
media pools in NetWorker.
1. On NetWorker Console, choose Media, open the context (right-click) menu for localhost, and then
choose Properties.
2. In the NetWorker Sever Properties window, choose the Configuration tab.
3. In the Worm tape handling section, clear the WORM tapes only in WORM pools box, and then
choose OK.
1. Label the tapes you want to back up your data to, create the target media pool, and add the tapes to
the pool.
You create a media pool and write data to a virtual tape by using the same procedures you do with
physical tapes. For detailed information, see the Backing Up Data section of the EMC NetWorker
Administration Guide.
2. Write data to the tape. You back up data by using the EMC NetWorker User application instead of the
EMC NetWorker Management Console. The EMC NetWorker User application installs as part of the
NetWorker installation.
Note
You use the EMC NetWorker User application to perform backups, but you view the status of
your backup and restore jobs in the EMC Management Console. To view status, choose the
Devices menu and view the status in the Log window.
1. On the Devices tab in the NetWorker Administration window, choose localhost or your EMC server,
and then choose Libraries.
2. Choose the library you imported from your virtual tape library.
3. From the list of tapes that you have written data to, open the context (right-click) menu for the tape
you want to archive, and then choose Eject/Withdraw.
4. In the confirmation box that appears, choose OK.
The archiving process can take some time to complete. The initial status of the tape is shown as IN
TRANSIT TO VTS.When archiving starts, the status changes to ARCHIVING.When archiving is completed,
the tape is no longer listed in the VTL.
1. Retrieve the archived tape from your VTS to a gateway-VTL. For instructions, see Retrieving the
Archived Tape from the VTS Back to Your Gateway-VTL (p. 124).
2. Use the EMC NetWorker software to restore the data. You do this by creating a restoring a folder file,
as you do when restoring data from physical tapes. For instructions, see the Using the NetWorker
User program section of the EMC NetWorker Administration Guide.
If you plan to continue using your gateway-VTL, see additional information in Where Do I Go from
Here? (p. 143)
You should follow these steps in order to ensure you free up the resources successfully.
1. Delete tapes from both your gateway's virtual tape library (VTL) and from the virtual tape shelf (VTS).
a. Cancel retrieval for any tapes that have the RETRIEVING status in your gateway's VTL.
For instructions, see Deleting Tapes from Your Gateway-VTL (p. 177).
d. Delete any tapes you have in the VTS.
For instructions, see Deleting Tapes from Your VTS (p. 182).
2. You can keep the gateway-VTL if you plan to use it. Otherwise, delete the gateway.
a. After deleting all the tapes that have the RETRIEVING or RETRIEVED status, delete the gateway.
For instructions, see Deleting Your Gateway by Using the AWS Storage Gateway Console and
Removing Associated Resources (p. 293).
b. Delete the AWS Storage Gateway VM from your on-premises host.
You can perform some of the gateway-VTL maintenance tasks on the AWS Management Console, such
as configuring your gateway's bandwidth rate limits and managing gateway software updates. If your
gateway-VTL is deployed on-premises, you can perform some of the maintenance tasks on the gateway's
local console, such as routing your gateway-VTL through a proxy and configuring your gateway to use a
static IP address. For information about these tasks, see
If you are running your gateway as an Amazon EC2 instance, you can preform specific maintenance
tasks on the Amazon EC2 console, such as adding and removing Amazon EBS volumes. For more
information, see
If you plan to deploy your gateway in production, you should take your real workload into consideration
in determining the disk sizes. For information on how to determine real-world disk sizes, see Managing
Local Storage for Your AWS Storage Gateway (p. 237). Also, consider cleaning up if you don't plan to
continue using your gateway-VTL. Cleaning up lets you avoid incurring charges. For information on
cleanup, see Step 6: Clean Up After the Example Exercise (p. 142).
After you deploy and activate your gateway, you can manage it how it works. Managing your gateway
includes tasks such as configuring cache storage and upload buffer space, working with volumes or virtual
tapes, doing general maintenance, troubleshooting, and monitoring your gateway's performance. If you
haven't set up a gateway, see Getting Started with AWS Storage Gateway (p. 10).
Topics
• Connecting iSCSI Initiators (p. 144)
• Managing Volumes, Tapes, and Snapshots (p. 161)
• Monitoring Your Gateway (p. 216)
• Managing Local Storage for Your AWS Storage Gateway (p. 237)
• Tagging Storage Gateway Resources (p. 248)
• Optimizing Gateway Performance (p. 250)
• Shutting Down and Starting Your Gateway (p. 251)
• Best Practices for Recovering Your Data (p. 253)
• Updating Bandwidth Rate Limits for Your Gateway (p. 255)
• Managing Gateway Updates Using the AWS Storage Gateway Console (p. 261)
• Performing Maintenance Tasks on the VM Local Console (p. 262)
• Performing Maintenance Tasks on the Amazon EC2 Gateway Local Console (p. 286)
• Configuring Security Groups for Your Amazon EC2 Gateway Instance (p. 292)
• Deleting Your Gateway by Using the AWS Storage Gateway Console and Removing Associated
Resources (p. 293)
• Troubleshoot Issues with Your Gateways (p. 297)
The iSCSI standard is an Internet Protocol (IP)–based storage networking standard for initiating and
managing connections between IP-based storage devices and clients. The following list defines some of
the terms that are used to describe the iSCSI connection and the components involved.
iSCSI initiator
The client component of an iSCSI network. The initiator sends requests to the iSCSI target. Initiators
can be implemented in software or hardware. AWS Storage Gateway only supports software initiators.
iSCSI target
The server component of the iSCSI network that receives and responds to requests from initiators.
Each of your volumes is exposed as an iSCSI target. Connect only one iSCSI initiator to each iSCSI
target.
Microsoft iSCSI initiator
The software program on Microsoft Windows computers that enables you to connect a client computer
(that is, the computer running the application whose data you want to write to the gateway) to an
external iSCSI-based array (that is, the gateway). The connection is made using the host computer's
Ethernet network adapter card. The Microsoft iSCSI initiator is already installed on Windows Server
2008 R2, Windows 7, Windows Server 2008, and Windows Vista. On these operating systems, you
don't need to install the initiator.
Red Hat iSCSI initiator
The iscsi-initiator-utils Resource Package Manager (RPM) package provides you with an iSCSI
initiator implemented in software for Red Hat Linux. The package includes a server daemon for the
iSCSI protocol.
Each type of gateway can connect to iSCSI devices, and you can customize those connections, as
described following.
Topics
• Connecting to Volumes on Your Volume Gateway (p. 145)
• Connecting to VTL Devices on Your Gateway (p. 146)
• Customizing Your Windows iSCSI Settings (p. 147)
• Connecting from a Red Hat Linux Client to Your iSCSI Targets (p. 149)
• Configuring CHAP Authentication for Your iSCSI Targets (p. 152)
The following diagram highlights the iSCSI target in the larger picture of the AWS Storage Gateway
architecture. For more information, see How AWS Storage Gateway Works (Architecture) (p. 2).
You can connect to your volume from either a Windows or Red Hat Linux client. You can optionally
configure CHAP for either client type.
Your gateway exposes your volume as an iSCSI target with a name you specify, prepended by
iqn.1997-05.com.amazon:. For example, if you specify a target name of myvolume, then the iSCSI
target you use to connect to the volume is iqn.1997-05.com.amazon:myvolume. For more information
about how to configure your applications to mount volumes over iSCSI, see Connecting to Volumes on
Your Volume Gateway (p. 145).
To See
Connect to your volume from Windows. Step 4: Connect Your Volumes to Your Windows
Client (p. 85) in the Getting Started section
Connect to your volume from Red Hat Linux. Connecting from a Red Hat Linux Client to Your
iSCSI Targets (p. 149)
Configure CHAP authentication for Windows and Configuring CHAP Authentication for Your iSCSI
Red Hat Linux. Targets (p. 152)
The following diagram highlights the iSCSI target in the larger picture of the AWS Storage Gateway
architecture. For more information on AWS Storage Gateway architecture, see Gateway–Virtual Tape
Library (Gateway-VTL) Architecture (p. 5).
For a gateway-VTL setup, connecting to your VTL devices by using a Microsoft iSCSI initiator is a two-step
process:
The Getting Started example setup provides instructions for both these steps. It uses the Symantec
NetBackup backup application. For more information, see Step 4: Connect Your Gateway-VTL Devices
to Your Windows Client (p. 108) and Configuring NetBackup Storage Devices (p. 113).
Warning
Make sure you are working in the CurrentControlSet subkey and not another control
set such as ControlSet001 or ControlSet002.
HKEY_Local_Machine\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-
11CE-BFC1-08002BE10318}
c. Find the subkey for the Microsoft iSCSI initiator, shown following as <Instance Number>.
HKEY_Local_Machine\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-
11CE-BFC1-08002BE10318}\<Instance Number>
Depending on what is installed on your computer, the Microsoft iSCSI initiator might not be the
subkey 0000. You can ensure that you have selected the correct subkey by verifying that the
string DriverDesc has the value Microsoft iSCSI Initiator, as shown in the following
example.
This value represents a hold time of 600 seconds. The example following shows the
MaxRequestHoldTime DWORD value with a value of 600.
HKEY_Local_Machine\SYSTEM\CurrentControlSet\Services\Disk
c. Open the context (right-click) menu for the TimeOutValue DWORD (32-bit) value, choose
Modify, and then change the value to 600.
This value represents a timeout of 600 seconds.The example following shows the TimeOutValue
DWORD value with a value of 600.
3. To ensure that the new configuration values take effect, restart your system.
Before restarting, you must make sure that the results of all write operations to volumes are flushed.
To do this, take any mapped storage volume disks offline before restarting.
1. Install the iscsi-initiator-utils RPM package, if it isn't already installed on your client.
a. Verify that the iSCSI daemon is running using one of the following commands.
b. If the status command doesn't return a status of running, then start the daemon using one of
the following commands.
For RHEL 7, use the following command. For RHEL 7, you usually don't need to explicitly start
the iscsid service.
3. To discover the volume or VTL device targets defined for a gateway, use the following discovery
command.
Substitute your gateway's IP address for the GATEWAY_IP variable in the preceding command. You
can find the gateway IP in the iSCSI Target Info properties of a volume on the AWS Storage Gateway
console.
The output of the discovery command will look like the following example output.
Your iSCSI qualified name (IQN) will be different than what is shown preceding, because IQN values
are unique to an organization. The name of the target is the name that you specified when you created
the volume. You can also find this target name in the iSCSI Target Info properties pane when you
select a volume on the AWS Storage Gateway console.
4. To connect to a target, use the following command.
Note that you need to specify the correct GATEWAY_IP and IQN in the connect command.
Warning
For gateways that are deployed on an Amazon EC2 instance, accessing the gateway over
a public Internet connection is not supported. The elastic IP address of the Amazon EC2
instance cannot be used as the target address.
5. To verify that the volume is attached to the client machine (the initiator), use the following command.
ls -l /dev/disk/by-path
The output of the command will look like the following example output.
After setting up your initiator, we highly recommend that you customize your iSCSI settings as
discussed in Customizing Your Linux iSCSI Settings (p. 151).
node.session.timeo.replacement_timeout = [replacement_timeout_value]
node.conn[0].timeo.noop_out_interval = [noop_out_interval_value]
node.conn[0].timeo.noop_out_timeout = [noop_out_timeout_value]
Note
The iscsid.conf settings must be made before discovering the gateway. If you have
already discovered your gateway or logged in to the target, or both, you can delete the
entry from the discovery database using the following command. Then you can
rediscover or log in again to pick up the new configuration.
a. If you are using the RHEL 5 initiator, open the /etc/udev/rules.d/50-udev.rules file and
find the following line.
Note
This rules file does not exist in RHEL 6 or 7 initiators, so you must create it.
To modify the timeout value in RHEL 6, use the following command and then add the lines of
code shown preceding.
To modify the timeout value in RHEL 7, use the following command and then add the lines of
code shown preceding.
3. Restart your system to ensure that the new configuration values take effect.
Before restarting, you must make sure that the results of all write operations to your volumes are
flushed. To do this, unmount storage volumes before restarting.
4. You can test the configuration by using the following command.
This command shows the udev rules that are applied to the iSCSI device.
To set up CHAP, you must configure it both on the AWS Storage Gateway console and in the iSCSI
initiator software that you use to connect to the target. Storage Gateway uses mutual CHAP, which is
when the initiator authenticates the target and the target authenticates the initiator.
1. Configure CHAP on the AWS Storage Gateway console, as discussed in To configure CHAP on the
AWS Storage Gateway console (p. 153).
2. In your client initiator software, complete the CHAP configuration.
• To configure mutual CHAP on a Windows client, see To configure mutual CHAP on a Windows
client (p. 154).
• To configure mutual CHAP on a Red Hat Linux client, see To configure mutual CHAP on a Red
Hat Linux client (p. 159).
In this procedure, you specify two secret keys that are used to read and write to a volume. These same
keys are used in the procedure to configure the client initiator.
1. On the AWS Storage Gateway console, choose the iSCSI Target Info tab of the volume for which
you want to configure CHAP.
2. Choose Configure CHAP Authentication.
In following screenshot, the target selected for CHAP configuration is a volume with the ID
vol-AE4B49D6.
In following screenshot, the device selected for CHAP configuration is virtual tape drive 01.
a. Select Enabled.
You can find the initiator name by using your iSCSI initiator software. For example, for Windows
clients, the name is the value on the Configuration tab of the iSCSI initiator. For more information,
see To configure mutual CHAP on a Windows client (p. 154).
Note
To change an initiator name, you must first disable CHAP, change the initiator name
in your iSCSI initiator software, and then enable CHAP with the new name.
c. For Secret used to Authenticate Initiator, type the secret requested.
This secret must be a minimum of 12 characters and a maximum of 16 characters long. This is
the secret key that the initiator (that is, the Windows client) must know to participate in CHAP
with the target.
d. For Secret used to Authenticate Target (Mutual CHAP), type the secret requested.
This secret must be a minimum of 12 characters and a maximum of 16 characters long. This is
the secret key that the target must know to participate in CHAP with the initiator.
Note
The secret used to authenticate the target must be different than the secret to
authenticate the initiator.
e. Choose Save.
4. On the iSCSI Target Info tab of the confirmation dialog box, confirm that CHAP authentication is
used.
In this procedure, you configure CHAP in the Microsoft iSCSI initiator using the same keys that you used
to configure CHAP for the volume on the console.
1. If the iSCSI initiator is not already started, on the Start menu of your Windows client computer,
choose Run, type iscsicpl.exe, and then choose OK to run the program.
2. Configure mutual CHAP configuration for the initiator (that is, the Windows client).
Note
The Initiator Name box is unique to your initiator and company. The name shown
preceding is the value that you used in the Configure CHAP Authentication dialog
box of the AWS Storage Gateway console.
The name shown in the example image is for demonstration purposes only.
b. Choose CHAP.
c. In the iSCSI Initiator Mutual Chap Secret dialog box, type the mutual CHAP secret value.
In this dialog box, you enter the secret that the initiator (the Windows client) uses to authenticate
the target (the storage volume). This secret allows the target to read and write to the initiator.
This secret is the same as the secret typed into the Secret used to Authenticate Target (Mutual
CHAP) box in the Configure CHAP Authentication dialog box. For more information, see
Configuring CHAP Authentication for Your iSCSI Targets (p. 152).
d. If the key that you typed is less than 12 characters or more than 16 characters long, an Initiator
CHAP secret error dialog box appears.
3. Configure the target with the initiator's secret to complete the mutual CHAP configuration.
b. If the target that you want to configure for CHAP is currently connected, disconnect the target
by selecting it and choosing Disconnect.
c. Select the target that you want to configure for CHAP, and then choose Connect.
4. If you provided the correct secret key, the target shows a status of Connected.
In this procedure, you configure CHAP in the Linux iSCSI initiator using the same keys that you used to
configure CHAP for the volume on the AWS Storage Gateway console.
1. Ensure that the iSCSI daemon is running and that you have already connected to a target. If you
have not completed these two tasks, see Connecting from a Red Hat Linux Client to Your iSCSI
Targets (p. 149).
2. Disconnect and remove any existing configuration for the target for which you are about to configure
CHAP.
a. To find the target name and ensure it is a defined configuration, list the saved configurations
using the following command.
The following command disconnects from the target named myvolume that is defined in the
Amazon iSCSI qualified name (IQN). Change the target name and IQN as required for your
situation.
The following command removes the configuration for the myvolume target.
a. Get the name of the initiator (that is, the client you are using).
The following command gets the initiator name from the /etc/iscsi/initiatorname.iscsi
file.
InitiatorName=iqn.1994-05.com.redhat:8e89b27b5b8
b. Open the /etc/iscsi/iscsid.conf file.
c. Uncomment the following lines in the file and specify the correct values for username, password,
username_in, and password_in.
node.session.auth.authmethod = CHAP
node.session.auth.username = username
node.session.auth.password = password
node.session.auth.username_in = username_in
node.session.auth.password_in = password_in
username The initiator name that you found in a previous step in this procedure.
The value starts with iqn. For example, iqn.1994-05.com.red-
hat:8e89b27b5b8 is a valid username value.
password The secret key used to authenticate the initiator (the client you are
using) when it communicates with the volume.
username_in The IQN of the target volume. The value starts with iqn and ends with
the target name. For example, iqn.1997-05.com.amazon:myvolume
is a valid username_in value.
password_in The secret key used to authenticate the target (the volume) when it
communicates to the initiator.
d. Save the changes in the configuration file, and then close the file.
4. Discover and log in to the target. To do so, follow the steps in Connecting from a Red Hat Linux
Client to Your iSCSI Targets (p. 149).
Topics
• Managing Volumes (p. 161)
• Managing Virtual Tapes (p. 175)
• Working with Snapshots (p. 184)
• Understanding AWS Storage Gateway Resources and Resource IDs (p. 215)
Managing Volumes
You can find information following about managing existing volumes, including adding new volumes,
removing existing volumes, and viewing the status of a volume.
Topics
• Managing Volumes for Gateway-Cached Volumes (p. 161)
• Managing Volumes for Gateway-Stored Volumes (p. 164)
• Understanding Volume Status (p. 169)
Topics
• Adding a Volume (p. 162)
• Removing a Volume (p. 164)
Important
If a cached volume keeps your primary data in Amazon S3, you should avoid processes that
read or write all data on the entire volume. For example, we don't recommend using virus-scanning
software that scans the entire cached volume. Such a scan, whether done on demand or
scheduled, causes all data stored in Amazon S3 to be downloaded locally for scanning, which
results in high bandwidth usage. Instead of doing a full disk scan, you can use real-time virus
scanning—that is, scanning data as it is read from or written to the cached volume.
Resizing a volume is not supported. To change the size of a volume, create a snapshot of the volume,
and then create a new cached volume from the snapshot. The new volume can be bigger than the volume
from which the snapshot was created. For steps describing how to remove a volume, see To remove a
volume (p. 164). For steps describing how to add a volume and preserve existing data, see To create a
cached volume using the console (p. 162).
All gateway-cached volume data and snapshot data is stored in Amazon S3 and is encrypted at rest using
server-side encryption (SSE). However, you cannot access this data by using the Amazon S3 API or
other tools such as the Amazon S3 console.
Adding a Volume
As your application needs grow, you might need to add more volumes to your gateway. As you add more
volumes, you must consider the size of the cache storage and upload buffer you allocated to the gateway.
The gateway must have sufficient buffer and cache space for new volumes. For more information, see
Managing the Upload Buffer (p. 238).
You can add volumes using the AWS Storage Gateway console or AWS Storage Gateway API. For
information on using the AWS Storage Gateway API to add volumes, see CreateCachediSCSIVolume.
The following procedure demonstrates using the console and assumes that you already have a deployed
and activated gateway.
Note
Resizing a volume is not supported. To change the size of a volume, create a snapshot
of the volume, and then create a new cached volume from the snapshot. The new
volume can be bigger than the volume from which the snapshot was created. For steps
describing how to remove a storage volume, see To remove a volume (p. 164). For steps
describing how to add a volume and preserve existing data, see To create a cached
volume using the console (p. 162).
b. For the size list next to the Capacity box, choose the appropriate size of the volume, GBs or
TBs. For information size limits and other limits, see AWS Storage Gateway Limits (p. 362)
c. For iSCSI Target Name, type a name.
The target name can contain lowercase letters, numbers, periods (.), and hyphens (-).This target
name appears as the iSCSI Target Node name on the Targets tab of the iSCSI Microsoft
Initiator UI after discovery. For example, the name target1 appears as
iqn.1997-05.com.amazon:target1. Ensure that the target name is globally unique within
your storage area network (SAN).
d. If you are creating a volume from a snapshot, for Based on Snapshot ID, type the snapshot
ID.
You can specify the ID of an existing AWS Storage Gateway or Amazon Elastic Block Store
(Amazon EBS) snapshot you previously created. In this case, the gateway creates the volume
and downloads data to the local cache storage only on first access of the data. For information
about how to find a snapshot you want to use, see Finding a Snapshot (p. 186).
Important
If the Amazon EBS volume you create the snapshot from contains data from a public
Amazon Machine Image (AMI), such as an AMI from AWS Marketplace, you will not
have the permission to create the volume.
Storage volumes cannot be created from snapshots that are encrypted or not owned
by you but shared with your account.
The size of the storage volume you create must be equal to or greater than the size of
the snapshot you create it from. For information on how to add a disk to your gateway
VM that can be used as a gateway-stored volume, see Step 2.3: Provision Local Disk
Storage for the Gateway VM (VMWare) (p. 26). Once you add such a volume, you can
access the contents of the volume from your on-premises applications. For more
information, see Connecting to Volumes on Your Volume Gateway (p. 145).
e. If you've configured your local gateway host with multiple network interface cards (NICs), specify
the IP address for the NIC to use for this volume in Host IP.
f. Check that Port shows 3260. The Port box shows the port to which to map an iSCSI target.
AWS Storage Gateway supports only port 3260.
g. Choose Create Volume.
Doing this creates a volume and makes your disk available as an iSCSI target for your applications
to connect to and store data on. For information on connecting to the iSCSI target, see Connecting
to Volumes on Your Volume Gateway (p. 145).
Note
If you want snapshots for this volume, you can either take a one-time snapshot or set
up a snapshot schedule for the volume. For more information, see Editing a Snapshot
Schedule (p. 194).
Removing a Volume
You might need to remove a volume as your application needs change—for example, if you migrate your
application to use a larger storage volume. Before removing a volume, make sure that there are no
applications currently writing to the volume. Also, make sure that there are no snapshots in progress for
the volume. If a snapshot schedule is defined for the volume, you can check it on the Snapshot Schedules
tab of the AWS Storage Gateway console. For more information, see Editing a Snapshot Schedule (p. 194).
You can remove volumes using the AWS Storage Gateway console or the AWS Storage Gateway API.
For information on using the AWS Storage Gateway API to remove volumes, see DeleteVolume. The
following procedure demonstrates using the console.
To remove a volume
Topics
• Adding a Volume (p. 164)
• Removing a Volume (p. 166)
Resizing the underlying disk of a volume is not supported. To change the size of an underlying disk,
delete the volume that is using the disk, resize the disk, and then create a new volume from the resized
disk. When you recreate the storage volume, be sure to preserve the data on the disk. For steps describing
how to remove a volume, see To remove the underlying local disk (VMware ESXi) (p. 167) or To remove
the underlying local disk (Microsoft Hyper-V) (p. 168). For steps describing how to add a volume and
preserve existing data, see To create a volume using the console (p. 165).
Adding a Volume
As your application needs grow, you might need to add more volumes to your gateway. As you add more
volumes, you must consider the size of your upload buffer you allocated to the gateway. The gateway
must have sufficient buffer space. For more information, see Managing the Upload Buffer (p. 238).
You can add volumes using the AWS Storage Gateway console or the AWS Storage Gateway API. For
information on using the API to add storage volumes, see CreateStorediSCSIVolume. The following
procedure demonstrates using the console and assumes that you already have a deployed and activated
gateway. Furthermore, the procedure assumes that there is at least one locally provisioned disk of the
gateway that is not used and can be allocated as a storage volume. For information on how to provision
a local disk for application storage, see Step 2.3: Provision Local Disk Storage for the Gateway VM
(VMWare) (p. 26).
a. For Disk, choose the local virtual disk that you provisioned for the gateway.
For information about provisioning disks, see Step 2.3: Provision Local Disk Storage for the
Gateway VM (VMWare) (p. 26).
b. If you want to preserve data on the disk, select Preserve existing data.
If you preserve data, AWS Storage Gateway bootstraps your volume upon creation, uploading
your volume's existing data to AWS. This process might take some time to complete.
When you create a volume from an existing snapshot and you don't want to preserve any existing
data on the disk, make sure Preserve existing data is clear.
c. For iSCSI Target Name, type a name.
The target name can contain lowercase letters, numbers, periods (.), and hyphens (-).This target
name appears as the iSCSI Target Node name on the Targets tab of the iSCSI Microsoft
Initiator UI after discovery. For example, the name target1 appears as
iqn.1997-05.com.amazon:target1. Ensure that the target name is globally unique within
your storage area network (SAN).
d. If you are creating a volume from a snapshot, for Based on Snapshot ID, type the snapshot
ID.
You can specify the ID of an existing AWS Storage Gateway or Amazon Elastic Block Store
(Amazon EBS) snapshot that you previously created. This approach is useful if you want to
restore a snapshot of another storage volume. In this case, the gateway creates the storage
volume and downloads your existing snapshot data to the volume. However, you don't need to
wait for all of the data to transfer from Amazon S3 to your volume before your application can
start accessing the volume and all of its data. For more information about snapshots, see Working
with Snapshots (p. 184).
Important
If the Amazon EBS volume you create the snapshot from contains data from a public
Amazon Machine Image (AMI), such as an AMI from AWS Marketplace, you will not
have the permission to create the volume.
Storage volumes cannot be created from snapshots that are encrypted or not owned
by you but shared with your account.
The size of the storage volume you create must be equal to or greater than the size of
the snapshot you create it from. For information on how to add a disk to your gateway
VM that can be used as a gateway-stored volume, see Step 2.3: Provision Local Disk
Storage for the Gateway VM (VMWare) (p. 26). Once you add such a volume, you can
access the contents of the volume from your on-premises applications. For more
information, see Connecting to Volumes on Your Volume Gateway (p. 145).
By default, AWS limits the maximum size of Amazon EBS volumes you can create per AWS
account. For information about default Amazon EBS volume limits, go to Amazon EBS Limits
in the Amazon EC2 User Guide. For information about how to increase these limits, go to Amazon
EC2 Service Limits.
e. If you've configured your local gateway host with multiple network interface cards (NICs), for
Host IP, specify the IP address for the NIC to use for this storage volume.
f. Check that Port shows 3260. The Port box shows the port to which to map an iSCSI target.
AWS Storage Gateway supports only port 3260.
g. Choose Create Volume.
Doing this creates a storage volume and makes your disk available as an iSCSI target for your
applications to connect to and store data on.
Choosing Create Volume also creates a snapshot schedule for your new volume. By default,
AWS Storage Gateway takes snapshots once a day.You can change both the time the snapshot
occurs each day and the frequency (every 1, 2, 4, 8, 12, or 24 hours). For more information, see
Editing a Snapshot Schedule (p. 194).
Note
Snapshots are incremental, compressed backups. For a given storage volume, the
gateway saves only the blocks that have changed since the last snapshot.This approach
minimizes the amount of storage that is used for your backups.
Removing a Volume
You might need to remove a volume as your application needs change—for example, if you migrate your
application to use a larger volume and you want to reclaim the underlying local disk space of the old
volume. To reclaim the local disk space, you need to remove the local disk from the VM.
Before removing the volume, make sure that there are no applications currently writing to the volume.
Also, make sure that there are no snapshots in progress for the volume. You can check the snapshot
schedule of storage volumes on the Snapshot Schedules tab of the console. For more information, see
Editing a Snapshot Schedule (p. 194).
You can remove volumes using the AWS Storage Gateway console or the AWS Storage Gateway API.
For information on using the API to remove volumes, see DeleteVolume. The following procedure
demonstrates using the console and either the vSphere client for a gateway deployed on the VMware
ESXi platform or the Microsoft Hyper-V Manager for a gateway deployed on the Microsoft Hyper-V platform.
This value is the disk's virtual device node value, which you use in the hypervisor client to help ensure
that you remove the correct disk.
VMware ESXi Follow the steps in To remove the underlying local disk (VMware ES-
Xi) (p. 167).
Microsoft Hyper-V Follow the steps in To remove the underlying local disk (Microsoft Hyper-
V) (p. 168).
1. In the vSphere client, open the context (right-click) menu for your gateway VM, and then choose Edit
Settings.
2. On the Hardware tab of the Virtual Machine Properties dialog box, choose the disk to remove, and
then choose Remove.
Verify that the Virtual Device Node value in the Virtual Machine Properties dialog box has the
same value that you noted in step 2 of the preceding procedure. Doing this helps ensure that you
remove the correct disk. The first SCSI controller displayed in the Microsoft Hyper-V Manager is
controller 0.
3. Choose the appropriate option in the Removal Options panel, and then choose OK to complete the
process of removing the disk.
1. In the Microsoft Hyper-V Manager, open the context (right-click) menu for your gateway VM, and
then choose Settings.
2. For Hardware in the Settings dialog box, choose the disk to remove, and then choose Remove.
The disks you add to a gateway are under the SCSI Controller entry in the Hardware list.
Verify that the Controller and Location values are the same as the value that you noted from a
previous step. Doing this helps ensure that you remove the correct disk.
The first SCSI controller displayed in the Microsoft Hyper-V Manager is controller 0.
Topics
• Gateway-Cached Volume Status Transitions (p. 172)
• Gateway-Stored Volume Status Transitions (p. 173)
You can see volume status on the AWS Storage Gateway console or by using one of the AWS Storage
Gateway API operations, for example DescribeCachediSCSIVolumes or DescribeStorediSCSIVolumes.
The following example shows volume status on the AWS Storage Gateway console. Volume status
appears in the Status column for each storage volume on your gateway. In the example, you can tell that
the volume highlighted is functioning normally because the status is AVAILABLE.
The following table describes each storage volume status, and if and when you should take action based
on each status. The AVAILABLE status is the normal status of a volume, and a volume should have this
status all or most of the time it is in use.
Status Meaning
AVAILABLE The volume is available for use. The AVAILABLE status is the normal running
status for a volume.
BOOTSTRAPPING The gateway is synchronizing data locally with a copy of the data stored in
AWS. You typically do not need to take any action for this status, because
the storage volume will automatically go to the AVAILABLE status in most
cases.
CREATING The volume is currently being created and is not ready to be used. The
CREATING status is transitional. No action is required.
DELETING The volume is currently being deleted. The DELETING status is transitional.
No action is required.
IRRECOVERABLE An error occurred from which the volume cannot recover. For information on
taking action in this situation, see Troubleshooting Volume Issues (p. 304).
Status Meaning
PASS THROUGH Data maintained locally is out of sync with data stored in AWS. Note that data
written to a volume while the volume is in PASS THROUGH status remains
in the cache until the volume status is BOOTSTRAPPING, and starts to upload
to AWS when BOOTSTRAPPING status begins.
The PASS THROUGH status can occur for several reasons, listed following:
• The PASS THROUGH status occurs if your gateway has run out of upload
buffer space. Your applications can continue to read from and write data
to your storage volumes while the volumes have the PASS THROUGH
status. However, the gateway is not writing any of your volume data to its
upload buffer or uploading any of this data to AWS. The gateway will con-
tinue to upload any data written to the volume before the volume entered
the PASS THROUGH status. Any pending or scheduled snapshots of a
storage volume fail while the volume has the PASS THROUGH status. For
information about what action to take when your storage volume has the
PASS THROUGH status because the upload buffer has been exceeded,
see Troubleshooting Volume Issues (p. 304).
• The PASS THROUGH status occurs when there is more than one storage
volume bootstrapping at once. Only one gateway storage volume can
bootstrap at a time. For example, if you create two storage volumes and
choose to preserve existing data on both of them, then the second storage
volume has the PASS THROUGH status until the first storage volume fin-
ishes bootstrapping. In this scenario, you do not need to take action. Each
storage volume will change to the AVAILABLE status automatically when
it is finished being created. You can read and write to the storage volume
while it has the PASS THROUGH or BOOTSTRAPPING status.
• Infrequently, the PASS THROUGH status can indicate that a disk allocated
for upload buffer use has failed. For information about what action to take
in this scenario, see Troubleshooting Volume Issues (p. 304).
RESTORING The volume is being restored from an existing snapshot. This status applies
only for gateway-stored volumes. For more information, see How AWS Storage
Gateway Works (Architecture) (p. 2).
If you restore two storage volumes at the same time, both storage volumes
show RESTORING as their status. Each storage volume will change to the
AVAILABLE status automatically when it is finished being created. You can
read and write to a storage volume and take a snapshot of it while it has the
RESTORING status.
Status Meaning
RESTORING PASS The volume is being restored from an existing snapshot and has encountered
THROUGH an upload buffer issue. This status applies only for gateway-stored volumes.
For more information, see How AWS Storage Gateway Works (Architec-
ture) (p. 2).
One reason that can cause the RESTORING PASS THROUGH status is if
your gateway has run out of upload buffer space. Your applications can
continue to read from and write data to your storage volumes while they have
the RESTORING PASS THROUGH status. However, no snapshots of a
storage volume can occur during the RESTORING PASS THROUGH status
period. For information about what action to take when your storage volume
has the RESTORING PASS THROUGH status because upload buffer capacity
has been exceeded, see Troubleshooting Volume Issues (p. 304).
UPLOAD BUFFER NOT The volume cannot be created or used, because the gateway does not have
CONFIGURED an upload buffer configured. For information on how to add upload buffer
capacity for volumes in a gateway-cached setup, see Adding and Removing
Upload Buffer Capacity for Your Gateway (p. 241). For information on how to
add upload buffer capacity for volumes in a gateway-stored setup, see Adding
and Removing Upload Buffer Capacity for Your Gateway (p. 241).
The diagram shows neither the UPLOAD BUFFER NOT CONFIGURED status nor the DELETING status.
Volume states in the diagram are represented by green, yellow, and red boxes. The colors are interpreted
as follows.
In the diagram, a transition between two states is depicted with a labeled line. For example, the transition
from the CREATING status to the AVAILABLE status is labeled as Create Basic Volume or Create Volume
from Snapshot and represents creating a cached volume. For more information about creating storage
volumes, see Adding a Volume (p. 162).
Note
The volume status of PASS THROUGH is depicted as yellow in this diagram and does not match
the color of this status icon in the Status box of the AWS Storage Gateway console.
The diagram shows neither the UPLOAD BUFFER NOT CONFIGURED status nor the DELETING status.
Volume states in the diagram are represented by green, yellow, and red boxes. The colors are interpreted
as follows.
In the following diagram, a transition between two states is depicted with a labeled line. For example, the
transition from the CREATING status to the AVAILABLE status is labeled as Create Basic Volume and
represents creating a storage volume without preserving data or creating the volume from a snapshot.
For more information about creating a storage volume, see To create a volume using the console (p. 165).
Note
The volume status of PASS THROUGH is depicted as yellow in this diagram and does not match
the color of this status icon in the Status box of the AWS Storage Gateway console.
Topics
• Managing Tapes in Your VTL (p. 176)
• Managing Tapes in Your VTS (p. 180)
• Understanding Tape Status (p. 183)
After you deploy a gateway-VTL, you can create tapes. These tapes appear in the virtual tape library.
For each gateway-VTL, there is one VTL. Your backup applications can access tapes in the VTL to read
and write data. These tapes are backed by Amazon Simple Storage Service (Amazon S3). That is, when
you write to these tapes, your gateway stores the data in Amazon S3.
AWS Storage Gateway also provides a virtual tape shelf where you can archive tapes in your VTL. A
VTS is analogous to an offsite archive location in a real-world tape library.
When you archive a tape, AWS Storage Gateway moves the tape from the VTL to the VTS. AWS Storage
Gateway provides one shelf per AWS region for your AWS account. If you set up multiple gateways, they
all share the same shelf for tape archival. You can retrieve a tape from the shelf to any gateway-VTL in
that region.
Note
You have one tape library for each gateway-VTL you create in your AWS account, but there is
only one virtual shelf for each AWS region for your account.
Tapes in a VTS are backed by Amazon Glacier. That is, when you archive a tape, AWS Storage Gateway
moves tape data from Amazon S3 to Amazon Glacier for long-term archival.
Topics
• Creating Virtual Tapes in Your Gateway-VTL (p. 177)
• Deleting Tapes from Your Gateway-VTL (p. 177)
• Archiving Tapes to the VTS (p. 178)
• Canceling Tape Retrieval (p. 179)
• Canceling Tape Archival (p. 179)
The console shows the tapes available for your gateway-VTL in the VTL Tape Cartridges tab.
When you have a large number of tapes in the library, the console supports searching for tapes by barcode,
by status, or by both. When you search by barcode, you can filter by status.
To search by status
After the tape status changes to AVAILABLE, your backup application can access the tapes.
Note
If the tape you want to delete from your gateway-VTL has a status of RETRIEVING, you must
first cancel the retrieval before deleting the tape. For more information, see Canceling Tape
Retrieval (p. 179). After the tape retrieval is canceled, the tape's status in the VTS changes back
to ARCHIVED. You can then delete the tape.
If the tape you want to delete from your gateway-VTL has a status of RETRIEVED, you must
first eject the tape using your backup application before deleting the tape. For instructions on
how to eject a tape using the Symantec NetBackup software, see Archiving the Tape (p. 122).
After the tape is ejected, the tape status in the VTS changes back to ARCHIVED. You can then
delete the tape.
4. In the confirmation dialog box that appears, select I want to delete the selected tape, and then
choose OK.
To archive a tape, you use your backup software. Tape archival process consists of three stages, seen
as the tape statuses IN TRANSIT TO VTS, ARCHIVING, and ARCHIVED:
• To archive a tape, use the command provided by your backup application. When the archival process
begins the tape status changes to IN TRANSIT TO VTS and the tape is no longer accessible to your
backup application. In this stage, your gateway-VTL is uploading data to AWS. If needed, you can
cancel the archival in progress. For more information about canceling archival, see Canceling Tape
Archival (p. 179).
Note
The steps for archiving a tape depend on your backup application. For detailed instructions,
see the documentation for your backup application.
• After the data upload to AWS completes, the tape status changes to ARCHIVING and AWS Storage
Gateway begins moving the tape to the VTS. You cannot cancel the archival process at this point.
• After the tape is moved to the VTS, its status changes to ARCHIVED. The tape is now visible in the
VTS, and you can retrieve the tape to any of your gateways in the region as the VTS. For more
information about tape retrieval, see Retrieving Tapes from a VTS to Your Gateway (p. 181).
The steps involved in archiving a tape depend on your backup software. For instructions on how to archive
a tape by using Symantec NetBackup software, see Archiving the Tape (p. 122).
The following procedure shows you how to cancel the retrieval process.
For information about how to find a tape in the console, see Managing Tapes in Your VTL (p. 176).
3. On the Details tab, choose Stop in the Status row.
4. In the dialog box that appears, choose OK. After the retrieval is canceled, AWS Storage Gateway
removes the tape from the list of tapes in your VTL, and changes the tape status in VTS from
RETRIEVING to ARCHIVED.
Note
You are charged for the portion the data that was retrieved from VTS before you canceled
the tape retrieval.
You can cancel archival only when the tape's status is IN TRANSIT TO VTS. Depending on factors such
as upload bandwidth and the amount of data being uploaded, this status might or might not be visible in
the AWS Storage Gateway console.
4. Choose Cancel Archival. After archiving is canceled, the status of the tape returns to its original
status.
Topics
• Retrieving Tapes from a VTS to Your Gateway (p. 181)
• Deleting Tapes from Your VTS (p. 182)
Note
You have one tape library for each gateway-VTL you create in your AWS account, but there is
only one virtual shelf per AWS region in your account.
Tapes in a VTS are backed by Amazon Glacier. That is, when you archive a virtual tape to the VTS, AWS
Storage Gateway moves tape data from Amazon S3 to Amazon Glacier for long-term archival. You must
first retrieve an archived tape before you can access data on the tape, and you can only read the data
from an archived tape that has been retrieved.
Each virtual tape in the VTS has an associated status. Over time, you might collect a large number of
tapes on the shelf, so the console supports search for a tape by barcode, status, or both. When you
search by barcode, you can filter by status.
To search by status
If you have multiple gateway-VTLs deployed in a region, you can retrieve a tape to only one gateway.
The retrieved tape is write-protected; you can only read the data on the tape.
Important
It takes up to 24 hours for the tape to be available in your gateway-VTL.
Note
There is a charge for retrieving tapes from the VTS. For detailed pricing information, see AWS
Storage Gateway Pricing.
4. In the Retrieve Tape wizard, for Tape Barcode, verify that the barcode identifies the virtual tape
you want to retrieve.
5. For Gateway, choose the gateway you want to retrieve the archived tape to, and then choose
Proceed.
The status of the tape changes from ARCHIVED to RETRIEVING. At this point, your data is being moved
from the virtual tape shelf (backed by Amazon Glacier) to the virtual tape library (backed by Amazon S3).
After all the data is moved, the status of the virtual tape in the VTS changes to RETRIEVED.
Note
Retrieved virtual tapes are read-only.
3. Choose the virtual tape you want to delete, and choose Delete Tape.
If a virtual tape has RETRIEVING status, the retrieval must be canceled before deleting the tape.
For more information, see Canceling Tape Retrieval (p. 179). If the tape has RETRIEVED status, it
must be archived before you delete it. For more information, see Archiving Tapes to the VTS (p. 178).
Topics
• Tape Status Information in a VTL (p. 183)
• Tape Status Information in a VTS (p. 184)
AVAILABLE The virtual tape is created and ready to be loaded into a Amazon S3
tape drive.
IN TRANSIT The virtual tape has been ejected and is being uploaded Amazon S3
TO VTS for archive. At this point, your gateway-VTL is uploading
data to AWS. If the amount of data being uploaded is small,
this status might not be seen. When the upload is com-
pleted, the status changes to ARCHIVING.
ARCHIVING The virtual tape is being moved by AWS Storage Gateway Data is being moved from
to the VTS, which is backed by Amazon Glacier. This Amazon S3 to Amazon Gla-
process happens after the data upload to AWS is com- cier
pleted.
DELETING The virtual tape is being deleted. Data is being deleted from
Amazon S3
RETRIEV- The virtual tape is being retrieved from the VTS to your Data is being moved from
ING gateway-VTL. Amazon Glacier to Amazon
S3
Note
The virtual tape can be retrieved only to a gate-
way-VTL.
RETRIEVED The virtual tape is retrieved from the VTS. The retrieved Amazon S3
tape is write-protected.
IRRECOV- The virtual tape cannot be read from or written to. This Amazon S3
ERABLE status indicates an error in your gateway-VTL.
The tape status also appears in the Details tab of each virtual tape.
The following table lists and describes the possible status values.
Status Description
ARCHIVED The virtual tape has been ejected and is uploaded to the VTS.
RETRIEVED The virtual tape has been retrieved from the VTS. The retrieved tape is read-only.
AWS Storage Gateway continually and asynchronously uploads data to AWS to keep your local data
synchronized with a copy stored in AWS. A benefit of this is that when snapshots are initiated, some or
all the data has already been uploaded and snapshots complete quickly. Furthermore, snapshots are
incremental—that is, the gateway uploads only the blocks of your volume that have changed since the
last snapshot. For example, if you have 100 GiB of data and only 5 GiB data changed since the last
snapshot, then the gateway uploads only the 5 GiB of changed data. You can delete any snapshot. AWS
Storage Gateway removes only the snapshot data that is not needed by other snapshots, letting you
restore a volume from any of the active snapshots.
How snapshots can be effectively used in your AWS Storage Gateway setup depends on the type of
gateway you set up—that is, gateway-cached or gateway-stored. For more information on gateway-cached
and gateway-stored architecture, see How AWS Storage Gateway Works (Architecture) (p. 2).
• For gateway-cached volumes, your volume data is already stored in Amazon S3.You can use snapshots
to preserve older versions of your data.
• For gateway-stored volumes, your volume data is stored on-premises. You can use snapshots for
durable, off-site backups in Amazon S3.
You can restore a snapshot either to a gateway volume or to an Amazon EBS volume. To restore a
snapshot to a gateway storage volume, first set up and activate a local gateway. Getting Started with
AWS Storage Gateway (p. 10) walks you through the steps of setting up a gateway. When you restore
a snapshot to an Amazon EBS volume, you can then attach the EBS volume to an Amazon EC2 instance.
For a complete list of charges and specific prices for Amazon EC2, see the Amazon EC2 Pricing page.
Topics
• Common Snapshot Tasks (p. 185)
• Snapshot Data Consistency (p. 186)
• Finding a Snapshot (p. 186)
• Editing a Snapshot Schedule (p. 194)
• Creating a One-Time Snapshot (p. 195)
• Deleting a Snapshot (p. 196)
• Restoring a Snapshot (p. 211)
To perform snapshot tasks, you should have one or more gateways that have been running for enough
time that there are snapshots to work with.You can work with snapshots using the AWS Storage Gateway
console, one of the AWS Software Development Kits (SDKs), or the AWS Storage Gateway REST API;
for more information on using the AWS Storage Gateway REST API, see Operations in AWS Storage
Gateway (p. 356). Following, we primarily show how to work with the console to perform gateway tasks.
Finding You might want to find a snapshot to see if it is complete, what time it was taken,
what the size of the snapshot is, or the name of the volume the snapshot was
taken from. For more information, see Finding a Snapshot (p. 186).
Scheduling When you first set up a stored volume, a default snapshot schedule of once a
day is set. You can change the frequency and timing of the snapshot schedule
to fit your application needs. For more information, see Editing a Snapshot
Schedule (p. 194).
Note
For gateway-stored volumes, you cannot delete the default snapshot
schedule.
Creating Snapshots for stored volumes are automatically created on a schedule by default,
and you can change the schedule of the snapshots as needed. You can also
take an instantaneous snapshot at any time for both stored and cached volumes.
For more information, see Creating a One-Time Snapshot (p. 195). For information
about troubleshooting snapshot issues, see Troubleshooting Snapshot Is-
sues (p. 307).
Restoring You can restore a snapshot to a new local volume, or you can use the snapshot
to create an Amazon EBS volume and attach that to an Amazon EC2 instance.
For more information, see Restoring a Snapshot to a Storage Volume (p. 212)
and Restoring a Snapshot to an Amazon EBS Volume (p. 214).
Deleting If you don't need a snapshot anymore, you can delete it. Because snapshots
are incremental backups, if you delete a snapshot only the data that is not needed
in other snapshots is deleted. For more information, see Deleting a Snap-
shot (p. 196).
If you need to guarantee that your operating system and file system have flushed their buffered data to
disk prior to taking a snapshot, you can do this by taking your storage volume offline before taking a
snapshot. Doing this forces your operating system to flush its data to disk. After the snapshot is complete,
you can bring the volume back online. In Microsoft Windows, use Disk Management (diskmgmt.msc)
to choose the storage volume and take it offline or bring it back online. To script this process in Windows,
you can use a command line tool such as Diskpart.exe. In Linux, you can use the mount and umount
commands.
Finding a Snapshot
When you want to restore a snapshot to a new volume—for example, in a disaster recovery scenario—or
to restore a previous version of your application data, you need to find a snapshot associated with the
volume in question. To locate a snapshot, you need to know the snapshot ID. You can find a snapshot
ID in several ways, including by using the AWS Storage Gateway console or Amazon EC2 console, or
programmatically by using one of the AWS Software Development Kits (SDKs).
Topics
• Finding Snapshots by Using the AWS SDK for Java (p. 188)
• Finding Snapshots by Using the AWS SDK for .NET (p. 190)
• Finding Snapshots by Using the AWS Tools for Windows PowerShell (p. 192)
If you list snapshots using the AWS Storage Gateway console, the list includes all snapshots generated
from your gateway and also snapshots that you might have generated from Amazon EBS volumes. If you
list snapshots on the Amazon EC2 console, you can see more snapshot properties to help you find your
snapshot. The Amazon EC2 console also has a search filtering capability. Both console experiences are
described following.
In some scenarios, you might need to search using several snapshot properties at once—for example,
status, start date, and description. In this case, you can use a programmatic approach. For examples,
see Finding Snapshots by Using the AWS SDK for Java (p. 188), Finding Snapshots by Using the AWS
SDK for .NET (p. 190), and Finding Snapshots by Using the AWS Tools for Windows PowerShell (p. 192).
When you find your snapshot, you can view its details, including the date and time the snapshot was
started and the storage volume on your gateway that was the source for the snapshot.
To find a snapshot for a volume using the AWS Storage Gateway console
3. Find the snapshot that you are looking for by finding its volume ID in the Volume ID column.
4. Choose the snapshot row to display the snapshot details.
To find a snapshot for a volume using the Amazon EC2 Management console
The EBS Snapshots window shows a list of your snapshots. This snapshot view offers more
functionality for finding snapshots than on the AWS Storage Gateway console. In particular, this view
shows descriptions that you can use for filtering results—for instance, there is a pattern to snapshot
descriptions that you can use to help find a snapshot. For example, in the console image following,
note these points:
• The row marked as 1 is a snapshot taken of an Amazon EBS volume. The name and description
fields are specified in the snapshot creation. This snapshot is not from an AWS Storage Gateway
operation.
• The row marked as 2 is a one-time, ad hoc snapshot taken from the AWS Storage Gateway
console. The descriptions for one-time snapshots contain "AWSConsole-Snapshot."
• The row marked as 3 is a snapshot of a volume taken from a snapshot schedule by AWS Storage
Gateway. The descriptions of scheduled snapshots contain the storage gateway ID, the volume
ID, and the word "Schedule" in this pattern: gatewayID:volumeID:Schedule
3. To find the snapshot that you are looking for in the list, type some or all of the volume ID for Search.
In the following example, only results containing vol-424 are shown. You can find the volume ID
on the AWS Storage Gateway console on the Volumes tab.
The following Java code example finds snapshots for a specified volume of a gateway using several
properties of the snapshot to filter the results returned. It uses the AWS SDK for Java and the Amazon
EC2 API. The Amazon EC2 API includes operations for working with snapshots.
You need to update the code and provide the service endpoint, a full or partial volume ID, a snapshot
status, and a number of days to indicate a cutoff date—snapshots taken before the cutoff are not returned.
For a list of AWS service endpoints you can use with Amazon EC2, see Regions and Endpoints in the
AWS General Reference.
import java.io.IOException;
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
import java.util.List;
import com.amazonaws.AmazonClientException;
import com.amazonaws.auth.PropertiesCredentials;
import com.amazonaws.services.ec2.AmazonEC2Client;
import com.amazonaws.services.ec2.model.DescribeSnapshotsRequest;
import com.amazonaws.services.ec2.model.DescribeSnapshotsResult;
import com.amazonaws.services.ec2.model.Filter;
import com.amazonaws.services.ec2.model.Snapshot;
FindingSnapshotsForAVolume();
try {
Filter[] filters = new Filter[2];
filters[0] = new Filter().withName("volume-id").withValues(volumeID);
DescribeSnapshotsRequest describeSnapshotsRequest =
new DescribeSnapshotsRequest().withFilters(filters);
DescribeSnapshotsResult describeSnapshotResult =
ec2Client.describeSnapshots(describeSnapshotsRequest);
The following C# code example finds snapshots for a specified volume of a gateway using several
properties of the snapshot to filter the results returned. It uses the AWS SDK for .NET and the Amazon
EC2 API. The Amazon EC2 API includes operations for working with snapshots.
Note
The following code example uses the AWS SDK for .NET version 1 and might include methods
that are no longer available in the current version of the SDK. For more information, see Migrating
Your Code to the Latest Version of the AWS SDK for .NET.
You need to update the code and provide the service endpoint, a full or partial volume ID, a snapshot
status, and a number of days to indicate a cutoff date for the snapshots to return. For a list of AWS service
endpoints you can use with Amazon EC2, see Regions and Endpoints in the AWS General Reference.
using System;
using System.Text;
using System.Collections.Generic;
using Amazon.EC2;
using Amazon.EC2.Model;
namespace AWSStorageGateway
{
class FindingSnapshotsExample
{
static AmazonEC2Config ec2Config;
static AmazonEC2Client ec2Client;
// A full volume id or partial fragment with "*".
static String volumeID = "vol-424*";
// Snapshot status to filter on: "completed", "pending", "error".
static String status = "completed";
// The number of days before which to not return snapshot results.
static int daysBack = 4;
// Service endpoint. Should be same region as volume/gateway.
static String serviceURLEC2 = "https://ec2.us-east-1.amazonaws.com";
FindingSnapshotsForAVolume();
DescribeSnapshotsRequest describeSnapshotsRequest =
new DescribeSnapshotsRequest().WithFilter(filters);
DescribeSnapshotsResponse describeSnapshotsResponse =
ec2Client.DescribeSnapshots(describeSnapshotsRequest);
Example : Finding Snapshots by Using the AWS Tools for Windows PowerShell
The following PowerShell script example finds snapshots for a specified volume of a gateway using
several properties of the snapshot to filter the results returned. It uses AWS Tools for Windows PowerShell
cmdlets for Amazon EC2. The Amazon EC2 cmdlets include operations for working with snapshots.
You need to update the script and provide a full or partial volume ID, a snapshot status, and a number
of days to indicate a cutoff date for the snapshots to return.
<#
.DESCRIPTION
Finds snapshots for a given volume and criteria about the snapshot.
.NOTES
PREREQUISITES:
1) AWS Tools for PowerShell from http://console.aws.amazon.com/powershell/
# Define filters.
$filter1 = New-Object Amazon.EC2.Model.Filter
$filter1.Name = "volume-id"
$filter1.Value.Add($volumeID)
For gateway-cached volumes, AWS Storage Gateway does not create a default snapshot schedule.
However, you can set up a snapshot schedule at any time if you need to. For gateway-cached volumes,
because your data is stored in Amazon S3, you don't need snapshots or a snapshot schedule for disaster
recovery purposes.
By using the following steps, you can edit the snapshot schedule for a volume.
The tab shows a list of your storage volumes on the selected gateway.
4. Choose a volume.
The AWS Storage Gateway console shows the snapshot schedule details for this volume.
5. Choose Modify Snapshot Schedule.
6. In the Modify Snapshot Schedule dialog box, update the schedule fields as needed. For example,
you can increase the default snapshot frequency of once a day or change the time a snapshot is
taken.
7. Choose Save to save the snapshot schedule updates.
5. Verify the snapshot using the console. For more information, see Finding a Snapshot (p. 186).
Deleting a Snapshot
You might want to delete a snapshot, for example, if you have taken many snapshots of a storage volume
over a period of time and you don't need the older snapshots. Because snapshots are incremental backups,
if you delete a snapshot, only the data that is not needed in other snapshots is deleted.
Topics
• Deleting Snapshots by Using the AWS SDK for Java (p. 197)
• Deleting Snapshots by Using the AWS SDK for .NET (p. 200)
• Deleting Snapshots by Using the AWS Tools for Windows PowerShell (p. 209)
On the AWS Storage Gateway console, you can delete a snapshots one at a time. To delete many
snapshots, you can use one of the AWS SDKs that supports AWS Storage Gateway operations. For
examples, see Deleting Snapshots by Using the AWS SDK for Java (p. 197), Deleting Snapshots by Using
the AWS SDK for .NET (p. 200), and Deleting Snapshots by Using the AWS Tools for Windows
PowerShell (p. 209).
3. Choose the snapshot that you want to delete, and then choose Delete.
The following Java code example lists the snapshots for each volume of a gateway and whether the
snapshot start time is before or after a specified date. It uses the AWS SDK for Java API for AWS Storage
Gateway and Amazon EC2. The Amazon EC2 API includes operations for working with snapshots.
You need to update the code and provide the service endpoint, your gateway Amazon Resource Name
(ARN), and the number of days back you want to save snapshots—snapshots taken before this cutoff
are deleted. You also need to specify the Boolean value viewOnly, which indicates whether you want
to view the snapshots to be deleted or to actually perform the snapshot deletions. You should run the
code first with just the view option (that is, with viewOnly set to true) to see what the code will delete.
For a list of AWS service endpoints you can use with AWS Storage Gateway, see Regions and Endpoints
in the AWS General Reference.
import java.io.IOException;
import java.util.ArrayList;
import java.util.Calendar;
import java.util.Collection;
import java.util.Date;
import java.util.GregorianCalendar;
import java.util.List;
import com.amazonaws.auth.PropertiesCredentials;
import com.amazonaws.services.ec2.AmazonEC2Client;
import com.amazonaws.services.ec2.model.DeleteSnapshotRequest;
import com.amazonaws.services.ec2.model.DescribeSnapshotsRequest;
import com.amazonaws.services.ec2.model.DescribeSnapshotsResult;
import com.amazonaws.services.ec2.model.Filter;
import com.amazonaws.services.ec2.model.Snapshot;
import com.amazonaws.services.storagegateway.AWSStorageGatewayClient;
import com.amazonaws.services.storagegateway.model.ListVolumesRequest;
import com.amazonaws.services.storagegateway.model.ListVolumesResult;
import com.amazonaws.services.storagegateway.model.VolumeInfo;
// The gatewayARN
public static String gatewayARN = "*** provide gateway ARN ***";
// The number of days back you want to save snapshots. Snapshots before
this cutoff are deleted
// if viewOnly = false.
public static int daysBack = 10;
// true = show what will be deleted; false = actually delete snapshots that
meet the daysBack criteria
public static boolean viewOnly = true;
ListDeleteVolumeSnapshotsExample.class.getResourceAs
Stream("AwsCredentials.properties")));
sgClient.setEndpoint(serviceURLSG);
}
public static List<VolumeInfo> ListVolumesForGateway()
{
List<VolumeInfo> volumes = new ArrayList<VolumeInfo>();
return volumes;
}
private static void DeleteSnapshotsForVolumes(List<VolumeInfo> volumes,
int daysBack2) {
DescribeSnapshotsRequest describeSnapshotsRequest =
new DescribeSnapshotsRequest().withFilters(filters);
DescribeSnapshotsResult describeSnapshotsResult =
ec2Client.describeSnapshots(describeSnapshotsRequest);
Time());
sb.append(s.getSnapshotId() + ", " + s.getStartTime().to
String());
sb.append(", meets criteria for delete? " + meetsCriteria);
sb.append(", deleted? ");
if (!viewOnly & meetsCriteria) {
sb.append("yes");
DeleteSnapshotRequest deleteSnapshotRequest =
new DeleteSnapshotRequest().withSnapshotId(s.getSnap
shotId());
ec2Client.deleteSnapshot(deleteSnapshotRequest);
}
else {
sb.append("no");
}
System.out.println(sb.toString());
}
}
}
The following C# code example allows an AWS Identity and Access Management (IAM) user to list the
snapshots for each volume of a gateway and determine whether the snapshot start time is before or after
a specified date (retention period) and delete snapshots that have passed the retention period. It uses
the AWS SDK for .NET API for AWS Storage Gateway and Amazon EC2. The Amazon EC2 API includes
operations for working with snapshots.
Note
The following code example uses the AWS SDK for .NET version 2 and 3.You can migrate older
versions of .NET to the newer version. For more information, see Migrating Your Code to the
Latest Version of the AWS SDK for .NET.
You need to update the code and provide the service endpoint, your gateway Amazon Resource Name
(ARN), and the number of days back you want to save snapshots—snapshots taken before this cutoff
are deleted. You also need to specify the Boolean value viewOnly, which indicates whether you want
to view the snapshots to be deleted or to actually perform the snapshot deletions. You should run the
code first with just the view option (that is, with viewOnly set to true) to see what the code will delete.
For a list of AWS service endpoints you can use with AWS Storage Gateway, see Regions and Endpoints
in the AWS General Reference.
First, you create an IAM user and attach the minimum IAM policy to the IAM user. Then you schedule
automated snapshots for your gateway.
The following code creates the minimum policy that allows an IAM user to delete snapshots. In this
example, the policy is named sgw-delete-snapshot.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "StmtEC2Snapshots",
"Effect": "Allow",
"Action": [
"ec2:DeleteSnapshot",
"ec2:DescribeSnapshots"
],
"Resource": [
"*"
]
},
{
"Sid": "StmtSgwListVolumes",
"Effect": "Allow",
"Action": [
"storagegateway:ListVolumes"
],
"Resource": [
"*"
]
}
]
}
The following C# code finds all snapshots in the specified gateway that match the volumes and the
specified cut off period and then deletes them.
using System;
using System.Collections.Generic;
using System.Text;
using Amazon.EC2;
using Amazon.EC2.Model;
using Amazon.StorageGateway.Model;
using Amazon.StorageGateway;
namespace DeleteStorageGatewaySnapshotNS
class Program
/*
*/
/* IAM AccessKey */
/* IAM SecretKey */
/*
*/
daysBack);
DeleteSnapshots(StorageGatewaySnapshots);
/*
*/
try
request.GatewayARN = GatewayARN;
response = sgClient.ListVolumes(request);
Console.WriteLine(OutputVolumeInfo(vi));
Console.WriteLine(ex.Message);
return response.VolumeInfos;
/*
*/
try
ownerValues.Add(OwnerID);
ownerFilter.Name = "owner-id";
ownerFilter.Values = ownerValues;
describeSnapshotsRequest.Filters.Add(ownerFilter);
statusValues.Add(SnapshotStatus);
statusFilter.Name = "status";
statusFilter.Values = statusValues;
describeSnapshotsRequest.Filters.Add(statusFilter);
volumeValues.Add(volumeID);
volumeFilter.Name = "volume-id";
volumeFilter.Values = volumeValues;
describeSnapshotsRequest.Filters.Add(volumeFilter);
DescribeSnapshotsResponse describeSnapshotsResponse =
ec2Client.DescribeSnapshots(describeSnapshotsRequest);
if (IsSnapshotPastRetentionPeriod(snapshotAge,
s.StartTime))
SelectedSnapshots.Add(s);
Console.WriteLine(ex.Message);
return SelectedSnapshots;
/*
*/
try
Console.WriteLine("Volume: " +
s.VolumeId +
s.SnapshotId +
+ response.HttpStatusCode.ToString());
Console.WriteLine(ex.Message);
/*
*/
/*
*/
"Volume Info:\n" +
vi.VolumeARN,
vi.VolumeType);
return volumeInfo;
Example : Deleting Snapshots by Using the AWS Tools for Windows PowerShell
The following PowerShell script example lists the snapshots for each volume of a gateway and whether
the snapshot start time is before or after a specified date. It uses the AWS Tools for Windows PowerShell
cmdlets for AWS Storage Gateway and Amazon EC2. The Amazon EC2 API includes operations for
working with snapshots.
You need to update the script and provide your gateway Amazon Resource Name (ARN) and the number
of days back you want to save snapshots—snapshots taken before this cutoff are deleted. You also need
to specify the Boolean value viewOnly, which indicates whether you want to view the snapshots to be
deleted or to actually perform the snapshot deletions. You should run the code first with just the view
option (that is, with viewOnly set to true) to see what the code will delete.
<#
.DESCRIPTION
Delete snapshots of a specified volume that match given criteria.
.NOTES
PREREQUISITES:
1) AWS Tools for PowerShell from http://console.aws.amazon.com/powershell/
.EXAMPLE
powershell.exe .\SG_DeleteSnapshots.ps1
#>
#ListVolumes
$volumesResult = Get-SGVolume -GatewayARN $gatewayARN
$volumes = $volumesResult.VolumeInfos
Write-Output("`nVolume List")
foreach ($volumes in $volumesResult)
{ Write-Output("`nVolume Info:")
Write-Output("ARN: " + $volumes.VolumeARN)
write-Output("Type: " + $volumes.VolumeType)
}
$volumeId = ($volumeARN-split"/")[3].ToLower()
{
$d = ([DateTime]::Now).AddDays(-$daysBack)
$meetsCriteria = $false
if ([DateTime]::Compare($d, $s.StartTime) -gt 0)
{
$meetsCriteria = $true
}
$sb = $s.SnapshotId + ", " + $s.StartTime + ", meets criteria for delete?
" + $meetsCriteria
if (!$viewOnly -AND $meetsCriteria)
{
$resp = Remove-EC2Snapshot -SnapshotId $s.SnapshotId
#Can get RequestId from response for troubleshooting.
$sb = $sb + ", deleted? yes"
}
else {
$sb = $sb + ", deleted? no"
}
Write-Output($sb)
}
}
Restoring a Snapshot
You can restore a snapshot of a volume to a new AWS Storage Gateway volume, or you can use the
snapshot to create an Amazon EBS volume and attach this volume to an Amazon EC2 instance. When
you restore the snapshot to a new AWS Storage Gateway volume, you can mount the volume as an
iSCSI device to your on-premises application server. You can then access the contents of the snapshot.
Overall, the process is similar to creating a new volume.
The use cases for restoring snapshots depend on the type of gateway you set up—for more information
on gateway types, see How AWS Storage Gateway Works (Architecture) (p. 2).
• For gateway-cached volumes, your volume data is already stored in Amazon S3. In this case, you
typically use snapshots to preserve older versions of your data. After initiating a snapshot restore to a
gateway-cached volume, snapshot data is downloaded to the local cache only upon first access of the
data.
• For gateway-stored volumes, your volume data is stored on-premises, In this case, you can use
snapshots for durable, off-site backups in Amazon S3. For example, if a local disk allocated as a storage
volume crashes, you can provision a new local disk and restore a snapshot to it during the volume
creation process. For more information on this approach, see Adding a Volume (p. 164).
After you initiate a snapshot restore to a gateway-stored volume, snapshot data is downloaded in the
background. This functionality means that once you create a volume from a snapshot, you don't need
to wait for all of the data to transfer from Amazon S3 to your volume before your application can start
accessing the volume and all of its data. If your application accesses a piece of data that has yet to be
loaded, the gateway immediately downloads the requested data from Amazon S3. The gateway then
continues loading the rest of the volume's data in the background.
Topics
• Restoring a Snapshot to a Storage Volume (p. 212)
• Restoring a Snapshot to an Amazon EBS Volume (p. 214)
3. In the snapshot list, choose the snapshot you want to create a storage volume from, and then note
its Snapshot ID value for use in a later step.
Important
If the Amazon EBS volume you create the snapshot from contains data from a public Amazon
Machine Image (AMI), such as an AMI from AWS Marketplace, you will not have the
permission to create the volume.
Storage volumes cannot be created from snapshots that are encrypted or not owned by you
but shared with your account.
The size of the storage volume you create must be equal to or greater than the size of the
snapshot you create it from. For information on how to add a disk to your gateway VM that
can be used as a gateway-stored volume, see Step 2.3: Provision Local Disk Storage for
the Gateway VM (VMWare) (p. 26). Once you add such a volume, you can access the
contents of the volume from your on-premises applications. For more information, see
Connecting to Volumes on Your Volume Gateway (p. 145).
4. In the navigation pane, choose the gateway to which you want to restore the snapshot.
5. Choose Create Volume.
6. Depending on the type of gateway you configured, choose one of the following steps.
i. In the Create Storage Volume dialog box, paste the snapshot ID that you copied previously
into the Based on Snapshot ID field.
ii. Choose a disk, type in a unique volume target name, and then choose Create Volume.
Note
If you select Preserve existing data, the volume creation process can take a long
time to complete.
i. In the Configure Your Gateway dialog box, paste the snapshot ID you copied previously
into the Based on Snapshot ID field.
ii. Choose a capacity for the disk, type in a unique volume target name, and then choose
Create Volume.
The size of your storage volume must be greater than or equal to the size of the snapshot.
You can now access the contents of this volume from your on-premises applications. For
more information on this process, see Connecting to Volumes on Your Volume
Gateway (p. 145).
• Follow the instructions in Creating an Amazon EBS Volume in the Amazon Elastic Compute
Cloud User Guide.
The volume size that you specify must be greater than or equal to the size of the snapshot. To
specify the snapshot to use, on the EBS Volumes pane of the Amazon EC2 console, choose
Create Volume, and then choose the snapshot's ID in the list. Alternatively, you can use the
Amazon EC2 API to create your Amazon EBS volumes.
Note
By default, AWS limits the maximum size of Amazon EBS volumes you can create per
AWS account. For information about default Amazon EBS volume limits, see Amazon
EBS Limits. in the Amazon EC2 User Guide. For information about how to increase
these limits, see Amazon EC2 Service Limits.
2. Attach the Amazon EBS volume to an Amazon EC2 instance. For more information, see Attaching
the Volume to an Instance in the Amazon Elastic Compute Cloud User Guide.
These resources and subresources have unique Amazon Resource Names (ARNs) associated with them
as shown in the following table.
Gateway arn:aws:storagegateway:region:account-id:gateway/gateway-id
ARN
AWS Storage Gateway also supports the use of EC2 instances and EBS volumes and snapshots. These
resources are Amazon EC2 resources that are used in AWS Storage Gateway.
and a unique combination of eight letters and numbers. For example, a gateway ID is of the form
sgw-12A3456B where sgw is the resource identifier for gateways. A volume ID takes the form
vol-3344CCDD where vol is the resource identifier for volumes.
For virtual tapes, you can prepend a up to a four character prefix to the barcode ID to help you organize
your tapes.
AWS Storage Gateway resource IDs are in uppercase. However, when you use these resource IDs with
the Amazon EC2 API, Amazon EC2 expects resource IDs in lowercase. You must change your resource
ID to lowercase to use it with the EC2 API. For example, in Storage Gateway the ID for a volume might
be vol-1122AABB. When you use this ID with the EC2 API, you must change it to vol-1122aabb.
Otherwise, the EC2 API might not behave as expected.
Important
IDs for Storage Gateway volumes and Amazon EBS snapshots created from gateway volumes
are changing to a longer format. Starting in December 2016, all new volumes and snapshots
will be created with a 17-character string. Starting in April 2016, you will be able to use these
longer IDs so you can test your systems with the new format. For more information, see Longer
EC2 and EBS Resource IDs.
For example, a volume ARN with the longer volume ID format will look like this:
arn:aws:storagegateway:us-west-2:111122223333:gateway/sgw-12A3456B/volume/vol-1122AABBCCDDEEFFG.
A snapshot ID with the longer ID format will look like this: snap-78e226633445566ee.
For more information, see Announcement: Heads-up – Longer AWS Storage Gateway volume
and snapshot IDs coming in 2016.
Topics
• Monitoring Your Volume Gateway (p. 216)
• Monitoring Your Gateway-VTL (p. 222)
• Monitoring the Upload Buffer (p. 225)
• Monitoring Cache Storage (p. 229)
• Understanding Storage Gateway Metrics (p. 230)
• Logging AWS Storage Gateway API Calls by Using AWS CloudTrail (p. 235)
AWS Storage Gateway provides Amazon CloudWatch metrics at no additional charge. Storage Gateway
metrics are recorded for a period of two weeks. By using these metrics, you can access historical
information and get a better perspective on how your gateway and volumes are performing. For detailed
information about CloudWatch, go to the Amazon CloudWatch Developer Guide.
the time taken to retrieve data from the AWS cloud. With metrics, you can track the health of your gateway
and set up alarms to notify you when one or more metrics fall outside a defined threshold.
Topics
• Using Amazon CloudWatch Metrics (p. 217)
• Measuring Performance Between Your Application and Gateway (p. 218)
• Measuring Performance Between Your Gateway and AWS (p. 219)
Storage Gateway provides CloudWatch metrics at no additional charge. Storage Gateway metrics are
recorded for a period of two weeks. By using these metrics, you can access historical information and
get a better perspective on how your gateway and volumes are performing. For detailed information about
CloudWatch, go to the Amazon CloudWatch Developer Guide.
Regardless of which method you choose to use to work with metrics, you must specify the following
information:
• The metric dimension to work with. A dimension is a name-value pair that helps you to uniquely identify
a metric. The dimensions for Storage Gateway are GatewayId, GatewayName, and VolumeId. In the
CloudWatch console, you can use the Gateway Metrics and Volume Metrics views to easily select
gateway-specific and volume-specific dimensions. For more information about dimensions, go to
Dimensions in the Amazon CloudWatch Developer Guide.
• The metric name, such as ReadBytes.
The following table summarizes the types of Storage Gateway metric data that you can use.
AWS/StorageG- GatewayId, Gate- These dimensions filter for metric data that describes aspects
ateway wayName of the gateway. You can identify a gateway to work with by
specifying both the GatewayId and the GatewayName dimen-
sions.
Working with gateway and volume metrics is similar to working with other service metrics. You can find
a discussion of some of the most common metrics tasks in the CloudWatch documentation listed following:
A statistic is an aggregation of a metric over a specified period of time. When you view the values of a
metric in CloudWatch, use the Average statistic for data latency (milliseconds), use the Sum statistic for
data throughput (bytes per second), and use the Samples statistic for input/output operations per second
(IOPS). For more information, see Statistics in the Amazon CloudWatch Developer Guide.
The following table summarizes the metrics and corresponding statistic you can use to measure the
throughput, latency, and IOPS between your applications and gateways.
Throughput Use the ReadBytes and WriteBytes metrics with the Sum CloudWatch stat-
istic. For example, the Sum value of the ReadBytes metric over a sample
period of 5 minutes divided by 300 seconds gives you the throughput as a rate
in bytes per second.
Latency Use the ReadTime and WriteTime metrics with the Average CloudWatch
statistic. For example, the Average value of the ReadTime metric gives you
the latency per operation over the sample period of time.
IOPS Use the ReadBytes and WriteBytes metrics with the Samples CloudWatch
statistic. For example, the Samples value of the ReadBytes metric over a
sample period of 5 minutes divided by 300 seconds gives you IOPS.
For the average latency graphs and average size graphs, the average is calculated over the total number
of operations (read or write, whichever is applicable to the graph) that completed during the period.
The following image shows the ReadBytes and WriteBytes metrics for a volume with the Sum statistic.
In the image, the cursor over a data point displays information about the data point including its value
and the number of bytes. Divide the bytes value by the Period value (5 minutes) to get the data throughput
at that sample point. For the point highlighted, the read throughput is 2,384,199,680 bytes divided by 300
seconds, which is 7.6 megabytes per second.
To measure the data input/output operations per second from an application to a volume
The following image shows the ReadBytes and WriteBytes metrics for a storage volume with the
Samples statistic. In the image, the cursor over a data point displays information about the data point,
including its value and the number of samples. Divide the samples value by the Period value (5 minutes)
to get the operations per second at that sample point. For the point highlighted, the number of write
operations is 24,373 bytes divided by 300 seconds, which is 81 write operations per second.
can be measured using the Storage Gateway metrics provided for you when you use the correct
aggregation statistic. The following table summarizes the metrics and corresponding statistic to use to
measure the throughput, latency, and input/output operations per second (IOPS) between your gateway
and AWS.
Throughput Use the ReadBytes and WriteBytes metrics with the Sum CloudWatch stat-
istic. For example, the Sum value of the ReadBytes metric over a sample
period of 5 minutes divided by 300 seconds gives you the throughput as a rate
in bytes per second.
Latency Use the ReadTime and WriteTime metrics with the Average CloudWatch
statistic. For example, the Average value of the ReadTime metric gives you
the latency per operation over the sample period of time.
IOPS Use the ReadBytes and WriteBytes metrics with the Samples CloudWatch
statistic. For example, the Samples value of the ReadBytes metric over a
sample period of 5 minutes divided by 300 seconds gives you IOPS.
Latency of data to Use the CloudDownloadLatency metric with the Average statistic. For ex-
AWS ample, the Average statistic of the CloudDownloadLatency metric gives you
the latency per operation.
The following image shows the CloudBytesUploaded metric for a gateway volume with the Sum statistic.
In the image, the cursor over a data point displays information about the data point, including its value
and bytes uploaded. Divide this value by the Period value (5 minutes) to get the throughput at that sample
point. For the point highlighted, the throughput from the gateway to AWS is 555,544,576 bytes divided
by 300 seconds, which is 1.7 megabytes per second.
The resulting time-ordered set of data points contains the latency in milliseconds.
Storage Gateway provides CloudWatch metrics at no additional charge. Storage Gateway metrics are
recorded for a period of two weeks. By using these metrics, you can access historical information and
get a better perspective of how your gateway-VTL and virtual tapes are performing. For detailed information
about CloudWatch, go to the Amazon CloudWatch Developer Guide.
Topics
• Using Amazon CloudWatch Metrics (p. 222)
• Measuring Performance Between Your Gateway-VTL and AWS (p. 223)
Regardless of which method you choose to use to work with metrics, you must specify the following
information:
• The metric dimension to work with. A dimension is a name-value pair that helps you to uniquely identify
a metric. The dimensions for Storage Gateway are GatewayId and GatewayName. In the CloudWatch
console, you can use the Gateway Metrics view to easily select gateway-specific and tape-specific
dimensions. For more information about dimensions, see Dimensions in the Amazon CloudWatch
Developer Guide.
• The metric name, such as ReadBytes.
The following table summarizes the types of Storage Gateway metric data that are available to you.
AWS/StorageG- GatewayId, Gate- These dimensions filter for metric data that describes aspects
ateway wayName of the gateway-VTL. You can identify a gateway-VTL to work
with by specifying both the GatewayId and the GatewayName
dimensions.
Working with gateway and tape metrics is similar to working with other service metrics. You can find a
discussion of some of the most common metrics tasks in the CloudWatch documentation listed following:
A statistic is an aggregation of a metric over a specified period of time. When you view the values of a
metric in CloudWatch, use the Average statistic for data latency (milliseconds), and use the Samples
statistic for input/output operations per second (IOPS). For more information, see Statistics in the Amazon
CloudWatch Developer Guide.
The following table summarizes the metrics and the corresponding statistic you can use to measure the
throughput, latency, and IOPS between your gateway-VTL and AWS.
Latency Use the ReadTime and WriteTime metrics with the Average CloudWatch
statistic. For example, the Average value of the ReadTime metric gives you
the latency per operation over the sample period of time.
Latency of data to Use the CloudDownloadLatency metric with the Average statistic. For ex-
AWS ample, the Average statistic of the CloudDownloadLatency metric gives you
the latency per operation.
The following image shows the CloudBytesUploaded metric for a gateway tape with the Sum statistic.
In the image, placing the cursor over a data point displays information about the data point, including its
value and the number of bytes uploaded. Divide this value by the Period value (5 minutes) to get the
throughput at that sample point. For the point highlighted, the throughput from the gateway-VTL to AWS
is 555,544,576 bytes divided by 300 seconds, which is 1.7 megabytes per second.
The resulting time-ordered set of data points contains the latency in milliseconds.
5. Define the alarm by defining the alarm state when the CloudBytesUploaded metric is greater than
or equal to a specified value for a specified time. For example, you can define an alarm state when
the CloudBytesUploaded metric is greater than 10 megabytes for 60 minutes.
6. Configure the actions to take for the alarm state. For example, you can have an email notification
sent to you.
7. Choose Create Alarm.
You monitor the upload buffer in the same way in both the gateway-cached and gateway-stored
architectures. For more information, see How AWS Storage Gateway Works (Architecture) (p. 2).
Note
The WorkingStoragePercentUsed, WorkingStorageUsed, and WorkingStorageFree
metrics represent the upload buffer for the gateway-stored volume setup only before the release
of the cached-volume feature in Storage Gateway. Now you should use the equivalent upload
buffer metrics UploadBufferPercentUsed, UploadBufferUsed, and UploadBufferFree.
These metrics apply to both gateway architectures.
The resulting time-ordered set of data points contains the percent used of the upload buffer.
Using the following procedure, you can create an alarm using the CloudWatch console. To learn more
about alarms and thresholds, see Creating CloudWatch Alarms.
a. On the Select Metric page of the Create Alarm Wizard, choose the
AWS/StorageGateway:GatewayId,GatewayName dimension, and then find the gateway that
you want to work with.
b. Choose the UploadBufferPercentUsed metric. Use the Average statistic and a period of 5
minutes.
c. Choose Continue.
a. On the Define Alarm page of the Create Alarm Wizard, identify your alarm by giving it a name
and description in the Name and Description boxes.
b. Define the alarm threshold.
In the following image, the alarm state is defined for UploadBufferPercentUsed greater than
or equal to 50 percent for 5 minutes.
c. Choose Continue.
a. In the Configure Actions page of the Create Alarm Wizard, choose Alarm for Alarm State.
b. Choose Choose or create email topic for Topic.
To create an email topic means that you set up an Amazon Simple Notification Service (Amazon
SNS) topic. For more information about Amazon SNS, go to Set Up Amazon SNS.
c. For Topic, type a descriptive name for the topic.
d. Choose Add Action.
e. Choose Continue.
a. In the Review page of the Create Alarm Wizard, review the alarm definition, metric, and
associated actions from this step. Associated actions include, for example, sending an email
notification.
a. Open the Amazon Simple Notification Service (Amazon SNS) email topic that is sent to the email
address that you specified when creating the topic.
You only monitor cache storage in the gateway-cached architecture. For more information, see How AWS
Storage Gateway Works (Architecture) (p. 2).
Total usage of cache Use the CachePercentUsed and TotalCacheSize metrics with the Average
statistic. For example, use the CachePercentUsed with the Average statistic
to analyze the cache usage over a period of time.
The TotalCacheSize metric changes only when you add cache to the
gateway.
Percentage of read re- Use the CacheHitPercent metric with the Average statistic.
quests that are served
from the cache Typically, you want CacheHitPercent to remain high.
Percentage of cache Use the CachePercentDirty metrics with the Average statistic.
that is dirty—that is, it
contains content that Typically, you want CachePercentDirty to remain low.
has not been uploaded
to AWS
To measure the cache's percentage dirty for a gateway and all its volumes
The resulting time-ordered set of data points contains the percentage of the cache that is dirty over the
5 minutes.
The resulting time-ordered set of data points contains the percentage of the cache that is dirty over the
5 minutes.
Gateway Metrics
For the discussion in this topic, we define gateway metrics as metrics that are scoped to the gateway—that
is, they measure something about the gateway. Because a gateway contains one or more volumes, a
gateway-specific metric is representative of all volumes on the gateway. For example, the
CloudBytesUploaded metric is the total number of bytes that the gateway sent to the cloud during the
reporting period. This metric includes the activity of all the volumes on the gateway.
When working with gateway metric data, you specify the unique identification of the gateway that you are
interested in viewing metrics for. To do this, you specify both the GatewayId and the GatewayName
values. When you want to work with metric for a gateway, you specify the gateway dimension in the
metrics namespace, which distinguishes a gateway-specific metric from a volume-specific metric. For
more information, see Using Amazon CloudWatch Metrics (p. 217).
Topics
The following table describes the Storage Gateway metrics that you can use to get information about
your gateway. The entries in the table are grouped functionally by measure.
Note
The reporting period for these metrics is 5 minutes.
Units: Percent
Units: Percent
Units: Percent
Cloud- The total number of compressed bytes that yes yes yes
BytesDown- the gateway downloaded from AWS during
loaded the reporting period.
Units: Bytes
Units: Milliseconds
CloudByte- The total number of compressed bytes that yes yes yes
sUploaded the gateway uploaded to AWS during the
reporting period.
Units: Bytes
Units: Bytes
Units: Bytes
Units: Percent
Units: Bytes
Units: Bytes
Units: Bytes
ReadBytes The total number of bytes read from your yes yes yes
on-premises applications in the reporting
period for all volumes in the gateway.
Units: Bytes
Units: Milliseconds
TotalCacheS- The total size of the cache in bytes. The yes no yes
ize sample is taken at the end of the reporting
period.
Units: Bytes
Write- The total number of bytes written to your yes yes yes
Bytes on-premises applications in the reporting
period for all volumes in the gateway.
Units: Bytes
Units: Milliseconds
TimeS- The time since the last available recovery yes yes no
inceLast- point. For more information, see Using
Recovery- Recovery Snapshots for Your Gateway-
Point Cached Setup (p. 307).
Units: Seconds
Note
Working storage applies only to
the gateway-stored volume setup.
The upload buffer applies to both
the gateway-stored and gateway-
cached volume setups. If you are
working with both types of gate-
way setups, you might find it
more convenient to use just the
corresponding upload buffer
metric, UploadBufferFree.
Units: Bytes
Units: Percent
Note
Working storage applies only to
the gateway-stored volume setup.
The upload buffer applies to both
the gateway-stored and gateway-
cached volume setups. If you are
working with both types of gate-
way setups, you might find it
more convenient to use just the
corresponding upload buffer
metric, UploadBufferUsed.
Units: Bytes
Volume Metrics
You can find information following about the Storage Gateway metrics that cover a volume of a gateway.
Each volume of a gateway has a set of metrics associated with it. Note that some volume-specific metrics
have the same name as certain gateway-specific metrics. These metrics represent the same kinds of
measurements but are scoped to the volume instead of the gateway. You must always specify whether
you want to work with either a gateway or a volume metric before working with a metric. Specifically,
when working with volume metrics, you must specify the VolumeId that identifies the storage volume for
which you are interested in viewing metrics. For more information, see Using Amazon CloudWatch
Metrics (p. 217).
The following table describes the Storage Gateway metrics that you can use to get information about
your storage volumes.
CacheHitPercent Percent of application read operations from the volume that are served from os e y
n
cache. The sample is taken at the end of the reporting period.
When there are no application read operations from the volume, this metric
reports 100 percent.
Units: Percent
CachePercentUsed The volume's contribution to the overall percent use of the gateway's cache os e y
n
storage. The sample is taken at the end of the reporting period.
Use the CachePercentUsed metric of the gateway to view overall percent use
of the gateway's cache storage. For more information, see Gateway Met-
rics (p. 230).
Units: Percent
CachePercentDirty The volume's contribution to the overall percentage of the gateway's cache that
os e y
n
has not been persisted to AWS. The sample is taken at the end of the reporting
period.
Use the CachePercentDirty metric of the gateway to view the overall per-
centage of the gateway's cache that has not been persisted to AWS. For more
information, see Gateway Metrics (p. 230).
Units: Percent
ReadBytes The total number of bytes read from your on-premises applications in the report-
sey
ing period.
Use this metric with the Sum statistic to measure throughput and with the
Samples statistic to measure IOPS.
Units: Bytes
ReadTime The total number of milliseconds spent to do read operations from your on- s e y
premises applications in the reporting period.
Units: Milliseconds
WriteBytes The total number of bytes written to your on-premises applications in the report-
sey
ing period.
Use this metric with the Sum statistic to measure throughput and with the
Samples statistic to measure IOPS.
Units: Bytes
WriteTime The total number of milliseconds spent to do write operations from your on- s e y
premises applications in the reporting period.
Units: Milliseconds
QueuedWrites The number of bytes waiting to be written to AWS, sampled at the end of the s e y
reporting period.
Units: Bytes
All of the Storage Gateway actions are logged and are documented in the Actions topic. For example,
calls to the ActivateGateway, ListGateways, and ShutdownGateway actions generate entries in the
CloudTrail log files.
Every log entry contains information about who generated the request. The user identity information in
the log helps you determine whether the request was made with root or IAM user credentials, with
temporary security credentials for a role or federated user, or by another AWS service. For more
information, go to the userIdentity field in the CloudTrail Event Reference in the AWS CloudTrail User
Guide.
You can store your log files in your bucket for as long as you want, but you can also define Amazon S3
lifecycle rules to archive or delete log files automatically. By default, your log files are encrypted by using
Amazon S3 server-side encryption (SSE).
You can choose to have CloudTrail publish Amazon Simple Notification Service (Amazon SNS) notifications
when new log files are delivered if you want to take quick action upon log file delivery. For more information,
see Configuring Amazon SNS Notifications.
You can also aggregate Storage Gateway log files from multiple AWS regions and multiple AWS accounts
into a single Amazon S3 bucket. For more information, see Aggregating CloudTrail Log Files to a Single
Amazon S3 Bucket.
The following example shows a CloudTrail log entry that demonstrates the ActivateGateway action.
{"Records":[{"eventVersion":"1.02","userIdentity":{"type":"IAMUser","prin
cipalId":"AIDAII5AUEPBH2M7JTNVC","arn":"arn:aws:iam::111122223333:user/StorageG
ateway-team/JohnDoe",
"accountId":"111122223333","accessKeyId":"AKIAIOSFODNN7EXAMPLE","user
Name":"JohnDoe"},"eventTime":"2014-12-04T16:19:00Z",
"eventSource":"storagegateway.amazonaws.com","eventName":"ActivateGate
way","awsRegion":"us-east-1","sourceIPAddress":"192.0.2.0",
"userAgent":"aws-cli/1.6.2 Python/2.7.6 Linux/2.6.18-164.el5",
"requestParameters":{"gatewayTimezone":"GMT-5:00","gateway
Name":"cloudtrailgatewayvtl","gatewayRegion":"us-east-1","activationKey":"EHFBX-
1NDD0-P0IVU-PI259-DHK88","gatewayType":"VTL"},
"responseElements":{"gatewayARN":"arn:aws:storagegateway:us-east-
1:111122223333:gateway/cloudtrailgatewayvtl"},"requestID":"54BT
FGNQI71987UJD2IHTCT8NF1Q8GLLE1QEU3KPGG6F0KSTAUU0",
"eventID":"635f2ea2-7e42-45f0-bed1-8b17d7b74265","eventType":"AwsApiC
all","apiVersion":"20130630","recipientAccountId":"444455556666"}]}
The following example shows a CloudTrail log entry that demonstrates the ListGateways action.
{"Records":[{"eventVersion":"1.02","userIdentity":{"type":"IAMUser","prin
cipalId":"AIDAII5AUEPBH2M7JTNVC","arn":"arn:aws:iam::111122223333:user/StorageG
ateway-team/JohnDoe",
"accountId:"111122223333", "accessKeyId":"AKIAIOSFODNN7EXAMPLE","user
Name":"JohnDoe"},"eventTime":"2014-12-03T19:41:53Z",
"eventSource":"storagegateway.amazonaws.com","eventName":"ListGate
ways","awsRegion":"us-east-1","sourceIPAddress":"192.0.2.0",
"userAgent":"aws-cli/1.6.2 Python/2.7.6 Linux/2.6.18-164.el5",
"requestParameters":null,"responseElements":null,"request
ID":"6U2N42CU37KAO8BG6V1I23FRSJ1Q8GLLE1QEU3KPGG6F0KSTAUU0",
"eventID":"f76e5919-9362-48ff-a7c4-d203a189ec8d","eventType":"AwsApiC
all","apiVersion":"20130630",
"recipientAccountId":"444455556666"}]}
Topics
• Managing the Upload Buffer (p. 238)
• Managing Cache Storage (p. 243)
• Configuring Local Storage for Your Gateway (p. 245)
The following table describes the types of local storage and the gateways that require each.
Note
When you provision disks, we strongly recommend that you do not provision local disks for the
upload buffer and cache storage that use the same underlying physical storage resource (that
is, the same disk). Underlying physical storage resources are represented as a data store in
VMware. When you deploy the gateway VM, you choose a data store on which to store the VM
files. When you provision a local disk (for example, to use as cache storage or upload buffer),
you have the option to store the virtual disk in the same data store as the VM or a different data
store.
If you have more than one data store, we strongly recommend that you choose one data store
for the cache storage and another for the upload buffer. A data store that is backed by only one
underlying physical disk, or that is backed by a less-performant RAID configuration such as RAID
1, can lead to poor performance in some situations when used to back both the cache storage
and upload buffer.
After the initial configuration and deployment of your gateway, you might find that you need to adjust the
local storage by adding or removing disks for an upload buffer or adding disks for cache storage.
Topics
• Sizing the Upload Buffer (p. 240)
• Adding and Removing Upload Buffer Capacity for Your Gateway (p. 241)
The following diagram highlights the upload buffer in the larger picture of the gateway-cached architecture.
For more information, see How AWS Storage Gateway Works (Architecture) (p. 2).
The following diagram highlights the upload buffer in the larger picture of the gateway-stored architecture.
For more information, see How AWS Storage Gateway Works (Architecture) (p. 2).
The following diagram highlights the upload buffer in the larger picture of the gateway-VTL architecture.
For more information, see How AWS Storage Gateway Works (Architecture) (p. 2).
The amount of upload buffer space your gateway requires depends on several factors, such as the rate
of incoming data to the volumes or tapes, the rate of outgoing data to AWS, and your network bandwidth.
If your applications continue to write data at a fast rate to your volumes or tapes, and network throughput
is not sufficient for the gateway to upload data to AWS, then eventually your upload buffer will be filled
with data waiting to be uploaded to AWS Your gateway’s ability to periodically create recovery points of
your tapes depends on having a properly configured upload buffer.
Note
For a gateway-VTL, if your upload buffer is too small, it might fill up while writing to a tape, which
can affect how quickly the gateway-VTL can create the next recovery point. For information
about sizing the upload buffer, see Sizing the Upload Buffer (p. 240). For more information about
recovery points, see You Need to Recover a Virtual Tape from a Malfunctioning
Gateway-VTL (p. 309).
• Use the sizing formula – As your application needs change, you should periodically review the
recommended formula for sizing the upload buffer. For more information, see Sizing the Upload
Buffer (p. 240).
• Use Amazon CloudWatch metrics for the upload buffer – You can proactively avoid the upload
buffer from filling up by monitoring the percentage of upload buffer space your gateway is using over
time. CloudWatch provides metrics such as UploadBufferPercentUsed for monitoring your gateway's
upload buffer usage (for more information, see Monitoring the Upload Buffer (p. 225)). You can set an
alarm to trigger a notification to you when upload buffer usage exceeds a threshold. If your upload
buffer is getting filled close to capacity, consider adding more buffer capacity to the gateway. For a full
list of Storage Gateway metrics, see Understanding Storage Gateway Metrics (p. 230).You can see the
current percentage of upload buffer usage on the Gateway tab of the Storage Gateway console.
• Optimize your environment – If the speed of incoming write operations is too high compared to the
outgoing network bandwidth, then the gateway might never catch up, no matter how much upload buffer
capacity you provision. In this case, consider optimizing your gateway for better performance by
allocating better hardware resources. For more information, see Optimizing Gateway
Performance (p. 250).
• Monitor volume status – A volume status can indicate an issue with the upload buffer. For example,
if the upload buffer capacity is reached, the volumes affected go into a PASS THROUGH (p. 172) status.
Although your applications can continue to operate, writing and reading data to and from your storage
volume, snapshots are not taken during this time.
To estimate the amount of upload buffer, you can determine the expected incoming and outgoing data
rates and plug them into the following formula.
If your incoming rate is higher than the outgoing rate, or if the formula returns a value less than 150 GiB,
we strongly recommend that you allocate at least 150 GiB of upload buffer space.
For example, assume that your business applications write text data to your gateway at a rate of 40 MB
a second for 12 hours a day and your network throughput is 12 MB a second. Assuming a compression
factor of 2:1 for the text data, you need to allocate approximately 690 GiB of space for the upload buffer.
((40 MB/sec) - (12 MB/sec * 2)) * (12 hours * 3600 seconds/hour) = 691200
megabytes
Note that you can initially use this approximation to determine the disk size that you want to allocate to
the gateway as upload buffer space. Add more upload buffer space as needed using the Storage Gateway
console. Also, you can use the Amazon CloudWatch operational metrics to monitor upload buffer usage
and determine additional storage requirements. For information on metrics and setting the alarms, see
Monitoring the Upload Buffer (p. 225).
If you decide that you need to change your upload buffer capacity, take one of the following actions.
To Do This
Add more upload buf- Follow the steps in Adding Upload Buffer Capacity (p. 241).
fer capacity to your
gateway.
Remove a disk alloc- Follow the steps in Removing Upload Buffer Capacity (p. 241).
ated as upload buffer
space.
Topics
• Adding Upload Buffer Capacity (p. 241)
• Removing Upload Buffer Capacity (p. 241)
• For information on adding buffer capacity with the console, see To configure local disks as upload
buffer or cache storage for gateway-cached volumes or gateway-VTLs (p. 246). This procedure assumes
that your activated gateway has at least one local disk available on its VM that you can allocate as an
upload buffer to the gateway.
• For information on adding buffer capacity with the API, see AddUploadBuffer.
The following procedure assumes that your activated gateway has at least one local disk allocated as an
upload buffer for the gateway. In the procedure, you start on the Storage Gateway console, leave the
console and use the VMware vSphere client or the Microsoft Hyper-V Manager to remove the disk, and
then return to the console.
3. In the Configure Your Activated Gateway dialog box, note the value of the virtual device node for
the local disk to be removed. You can find the node value in the Local Disks column. For example,
in the following dialog box, the device node value SCSI (0:2) is highlighted.
You use the disk's virtual device node in the vSphere client to help ensure that you remove the correct
disk.
4. Shut down the gateway by following the steps in the Shutting Down and Starting Your Gateway (p. 251)
procedure.
Note
Before shutting down the gateway, ensure that no application is writing data to it and that
no snapshots are in progress. You can check the snapshot schedule of volumes on the
Snapshot Schedules tab of the Storage Gateway console. For more information, see
Editing a Snapshot Schedule (p. 194).
5. To remove the underlying local disk, do one of the following procedures.
VMware ESXi Follow the steps in To remove a disk allocated for the upload buffer (VMware
ESXi) (p. 380).
Microsoft Hyper-V Follow the steps in To remove an underlying disk allocated for the upload
buffer (Microsoft Hyper-V) (p. 382).
Important
After removing a disk used as an upload buffer, you must turn the gateway back on before
adding new disks to the VM.
7. On the Volumes tab of the Storage Gateway console, check that all volumes have a status of
AVAILABLE (p. 172).
After a gateway restart, a storage volume might go through the PASS THROUGH (p. 172) and
BOOTSTRAPPING (p. 172) states as the gateway adjusts to the upload buffer disk that you removed.
A volume that passes through these two states will eventually come to the AVAILABLE (p. 172) state.
You can use a volume during the PASS THROUGH and BOOTSTRAPPING states. However, you
cannot take snapshots of the volume in these states.
Topics
• Sizing Cache Storage (p. 244)
• Adding Cache Storage for Your Gateway (p. 245)
The following diagram highlights the cache storage in the larger picture of the gateway-cached architecture.
For more information, see How AWS Storage Gateway Works (Architecture) (p. 2).
The following diagram highlights the cache storage in the larger picture of the gateway-VTL architecture.
For more information, see How AWS Storage Gateway Works (Architecture) (p. 2).
The amount of cache storage your gateway requires depends on how much of your application data you
want to provide low-latency access to. The cache storage must be at least the size of the upload buffer.
This guideline helps ensure that the cache storage is large enough to persistently hold all data that has
not yet been uploaded to Amazon S3. When your cache storage has filled up with dirty data (that is, data
that has not been uploaded to AWS), application write operations to your volumes or tapes are blocked
until more cache storage becomes available. However, application read operations from the volume or
tapes are still allowed.
Here are some guidelines you can follow to help ensure you have adequate cache storage allocated for
your gateway.
• Use the sizing formula. – As your application needs change, you should periodically review the
recommended formula for sizing cache storage. For more information, see Sizing Cache Storage (p. 244).
• Use Amazon CloudWatch metrics. – You can proactively avoid filling up cache storage with dirty
data by monitoring how cache storage is being used—particularly, by reviewing cache misses.
CloudWatch provides usage metrics such as the CachePercentDirty and CacheHitPercent metrics
for monitoring how much of the gateway's cache storage has not been uploaded to Amazon S3. You
can set an alarm to trigger a notification to you when the percentage of the cache that is dirty exceeds
a threshold or the cache hit percentage falls below a threshold. Both of these can indicate that the
cache storage size is not adequate for the gateway. For a full list of Storage Gateway metrics, see
Understanding Storage Gateway Metrics (p. 230).
You can initially use this approximation to provision disks for the cache storage.You can then use Amazon
CloudWatch operational metrics to monitor the cache storage usage and provision more storage as
needed using the console. For information on using the metrics and setting up alarms, see Monitoring
Cache Storage (p. 229).
If you decide that you need to increase your gateway's cache storage capacity, follow the steps in Adding
Cache Storage for Your Gateway (p. 245).
You can add more cache storage to your gateway without interrupting existing gateway functions and
with the gateway VM turned on.
Note
Removing a disk allocated as cache storage is currently not supported.
You can add more cache storage by using the Storage Gateway console or the Storage Gateway API:
• For information on adding cache storage using the console, To configure local disks as upload buffer
or cache storage for gateway-cached volumes or gateway-VTLs (p. 246). This procedure assumes that
your activated gateway has at least one local disk available on its VM that you can allocate as cache
storage for the gateway.
• For information on adding cache storage by using the API, see AddCache.
Topics
• Configuring an Upload Buffer and Cache Storage (Gateway-Cached Volumes or Gateway-VTLs) (p. 245)
• Configuring an Upload Buffer for Your Gateway-Stored Volumes (p. 246)
To configure local disks as upload buffer or cache storage for gateway-cached volumes
or gateway-VTLs
4. In the Configure Your Activated Gateway wizard, verify that there are local disks available to
configure as an upload buffer and cache storage.
The wizard shows a list of available disks on your local VM. If there are no local disks available, you
must first add disks to your gateway VM. For more information on doing so, see Step 2.3: Provision
Local Disk Storage for the Gateway VM (VMWare) (p. 26).
Important
After configuring a disk as upload buffer storage, you lose any pre-existing data on the disk.
5. For each disk that you want to use, choose Use for Upload Buffer or Use for Cache Storage from
the list next to the local disk.
6. Choose Save to save your configuration.
4. In the Configure Local Upload Buffer wizard, verify that there are local disks available to configure
as an upload buffer.
The wizard shows a list of available disks on your local VM. If there are no local disks available, you
must first add disks to your gateway VM. For more information on doing so, see Step 2.3: Provision
Local Disk Storage for the Gateway VM (VMWare) (p. 26).
Important
After configuring a disk as upload buffer storage, you lose any pre-existing data on the disk.
5. Select the check box next to the disk or disks that you want to allocate to the gateway as the upload
buffer, and then choose Next. The Next button is enabled only if you select at least one disk.
6. In the confirmation dialog box, read the text, select the confirmation check box, and then choose
Confirm.
Doing this allocates the disk as upload buffer for the gateway.
As an example, you can use tags to identify Storage Gateway resources used by each department in
your organization. You might tag gateways and volumes used by your accounting department like this:
(key=department and value=accounting). You can then filter with this tag to identify all gateways
and volumes used by your accounting department and use the information to determine cost. For more
information, see Using Cost Allocation Tags and Working with Tag Editor.
If you archive a virtual tape that is tagged, the tape maintains its tags in the virtual tape shelf (VTS).
Similarly, if you retrieve a tape from the VTS to another gateway, the tags are maintained in the new
gateway. Tagging resources in the VTS works the same way as it does in the virtual tape library.
Tags don’t have any semantic meaning but rather are interpreted as strings of characters.
To add a tag
For example, to tag a gateway, choose the gateway you want to tag, choose the Gateway tab, and
then choose Tag Gateway.
• If the resource you want to tag is a volume, choose the Volume tab, choose the volume, and then
choose Tag Volume.
• If the resource you want to tag is a tape, choose the VTL Tape Cartridges tab, choose the tape,
and then choose Tag Tape.
The name, ID, or barcode of your resource is displayed in the Tags dialog box.
Note
The Tag resource button doesn’t appear until you select a volume or tape.
4. In the Tags dialog box, type a key for Key box and a value for Value.
Note
You can leave the Value box blank.
5. Choose Add Tag to add more tags. You can add multiple tags to a resource.
6. When you’re done adding tags, choose Save.
To edit a tag
To delete a tag
AWS Storage Gateway supports using eight CPUs in your gateway host server. You can use eight
CPUs to significantly improve the performance of your gateway. We recommend the following gateway
configuration for your gateway host server:
• Eight CPUs
• 7.5 GiB RAM
• Disk 1 attached to paravirtual controller 1, to be used as the gateway cache as follows:
• Use RAID 10 backed by 15,000 RPM 6 Gbps disks with a stripe size of 256 K each
• Use a Virtual Machine File System version 5 (VMFS5) data store created on the RAID 10
• Use a virtual disk created on VMFS5 as the cache for the gateway
• Disk 2 attached to paravirtual controller 2, to be used as the gateway upload buffer as follows:
• Use RAID 10 backed by 15,000 RPM 6 Gbps disks with a stripe size of 512 K each
• Use a VMFS5 data store created on the RAID 10
• Use a virtual disk created on VMFS5 as the upload buffer for the gateway
• Network adapter 1 configured on VM network 1:
• Use VM network 1 and add a 1 Gbps network adapter 1 to be used for ingestion
• Network adapter 2 configured on VM network 2:
• Use VM network 2 and add a 1 Gbps network adapter 2 to be used to connect to AWS
While the gateway is shutting down, you might see a message that your gateway is in the process
of shutting down.
6. On the navigation pane, choose the gateway.
To start a gateway
Topics
• Recovering from an Unexpected Virtual Machine Shutdown (p. 253)
• Recovering Your Data from a Malfunctioning Gateway or VM (p. 253)
• Retrieving Your Data from an Irrecoverable Volume (p. 254)
• Recovering Your Data from an Irrecoverable Tape (p. 254)
• Recovering Your Data from a Malfunctioning Cache Disk (p. 254)
• Recovering Your Data from a Corrupted File System (p. 255)
Important
AWS Storage Gateway doesn’t support recovering a gateway VM from a snapshot that is created
by your hypervisor. If your gateway VM malfunctions, activate a new gateway and recover your
data to that gateway using the instructions following.
• If an outage causes network connectivity issues, you can troubleshoot the issue. For information about
how to test network connectivity, see Testing Your Gateway Connection to the Internet (p. 271).
• For gateway-cached volumes and gateway-VTL setups, when your gateway becomes reachable, your
volumes or tapes go into BOOTSTRAPPING status. This functionality ensures that your locally stored
data continues to be synchronized with AWS. For more information on this status, see
BOOTSTRAPPING (p. 172).
• If your gateway malfunctions and issues occur with your volumes or tapes as a result of an unexpected
shutdown, you can recover your data. For information about how to recover your data, see the sections
following that apply to your scenario.
If your gateway-cached volume becomes unreachable, you can use the following steps to recover your
data from a recovery snapshot:
1. In the AWS Management Console, choose the malfunctioning gateway, choose the volume you want
to recover, and then create a recovery snapshot from it.
2. Deploy and activate a new gateway-cached volume. Or, if you have an existing functioning
gateway-cached volume, you can use that gateway and volume to recover your volume data.
3. Find the snapshot you created and restore it to a new volume on the functioning gateway.
4. Mount the new volume as an iSCSI device on your on-premises application server. You can access
the data on the volume from this server. For gateways hosted on an Amazon Elastic Compute Cloud
(Amazon EC2) instance, you can use the snapshot to create an Amazon Elastic Block Store (Amazon
EBS) volume and attach it to an EC2 instance.
For detailed information on how to recover gateway-cached data from a recovery snapshot, see Using
Recovery Snapshots for Your Gateway-Cached Setup (p. 307).
If your gateway-VTL or the hypervisor host encounters an unrecoverable failure, you can use the following
steps to recover the tapes from the malfunctioning gateway-VTL to another gateway-VTL:
1. Identify a gateway-VTL you want to use as the recovery target or create you can create a new one.
2. Disable the malfunctioning gateway.
3. Create recovery tapes for each tape you want to recover and specify the target gateway-VTL.
4. Delete the malfunctioning gateway-VTL.
For detailed information on how to recover the tapes from a malfunctioning gateway-VTL to another
gateway-VTL, see You Need to Recover a Virtual Tape from a Malfunctioning Gateway-VTL (p. 309).
1. Create a new volume from the disk that was used to create the irrecoverable volume.
2. Preserve existing data when you are creating the new volume.
3. Delete all pending snapshot jobs for the irrecoverable volume.
4. Delete the irrecoverable volume from the gateway.
For detailed information on how to retrieve your data from the irrecoverable volume to a new volume, see
The Console Says That Your Volume Is Irrecoverable (p. 304).
• If you need the data on the irrecoverable tape, you can recover the tape to a new gateway.
• If you don't need the data on the tape, and the tape has never been archived to VTS, you can simply
delete the tape from your gateway-VTL.
For detailed information about how to recover your data or resolve the failure if your tape is
IRRECOVERABLE, see Troubleshooting Irrecoverable Tapes (p. 311).
• If the malfunction occurred because a cache disk was removed from your host, shut down the gateway,
re-add the disk, and restart the gateway.
• If the cache disk is corrupted or not accessible, shut down the gateway, reset the cache disk, reconfigure
the disk for cache storage, and restart the gateway.
For detailed information, see You Need to Recover a Virtual Tape from a Malfunctioning Cache Disk (p. 310).
1. Shut down your virtual machine and use the AWS Storage Gateway Management Console to create
a recovery snapshot. This snapshot represents the most current data stored in AWS.
Note
You use this snapshot as a fallback if your file system can't be repaired or the snapshot
creation process can't be completed successfully.
For information about how to create a recovery snapshot, see Using Recovery Snapshots for Your
Gateway-Cached Setup (p. 307).
2. Use the fsck command to check your file system for errors and attempt a repair.
3. Restart your gateway VM.
4. When your hypervisor host starts to boot up, press and hold down any key (for example, the spacebar)
to enter the grub boot menu.
5. From the menu, choose the CentOS menu, and then press e to edit.
6. Choose the kernel line (the second line), and then press e to edit.
7. Append the following option to the kernel command line: init=/bin/bash. Use a space to separate
the previous option from the option you just appended.
8. Press Return to save the changes.
9. Press b to boot your computer with the modified kernel option. Your computer will boot to a bash#
prompt.
10. Type /sbin/fsck to run this command manually from the prompt, to check and repair your file system.
11. When the file system check and repair is complete, reboot the instance. The grub settings will revert
to the original values, and the gateway will boot up normally.
12. Wait for snapshots that are in-progress from the original gateway to complete, and then validate the
snapshot data.
You can continue to use the original volume as-is, or you can create a new gateway with a new volume
based on either the recovery snapshot or the completed snapshot. Alternatively, you can create a new
volume from any of your completed snapshots from this volume.
bandwidth used by your gateway. By default, an activated gateway has no rate limits on upload or
download.
You can specify the rate limit by using the AWS Management Console, or programmatically by using
either the AWS Storage Gateway API (see UpdateBandwidthRateLimit) or an AWS Software Development
Kit (SDK). By throttling bandwidth programmatically, you can change limits automatically throughout the
day—for example, by scheduling tasks to change the bandwidth. As described directly following, you can
change these limits by using the AWS Storage Gateway console. Or, for information about changing
bandwidth rate limits programmatically, see the following topics.
Topics
• Updating Gateway Bandwidth Rate Limits Using the AWS SDK for Java (p. 256)
• Updating Gateway Bandwidth Rate Limits Using the AWS SDK for .NET (p. 258)
• Updating Gateway Bandwidth Rate Limits Using the AWS Tools for Windows PowerShell (p. 260)
5. In the Edit Rate Limits dialog box, type new limit values, and then choose Save.
Example : Updating Gateway Bandwidth Limits Using the AWS SDK for Java
The following Java code example updates a gateway's bandwidth rate limits. You need to update the
code and provide the service endpoint, your gateway Amazon Resource Name (ARN), and the upload
and download limits. For a list of AWS service endpoints you can use with AWS Storage Gateway, see
Regions and Endpoints in the AWS General Reference.
import java.io.IOException;
import com.amazonaws.AmazonClientException;
import com.amazonaws.auth.PropertiesCredentials;
import com.amazonaws.services.storagegateway.AWSStorageGatewayClient;
import com.amazonaws.services.storagegateway.model.UpdateBandwidthRateLimitRe
quest;
import com.amazonaws.services.storagegateway.model.UpdateBandwidthRateLimitRes
ult;
// The gatewayARN
public static String gatewayARN = "*** provide gateway ARN ***";
// The endpoint
static String serviceURL = "https://storagegateway.us-east-1.amazonaws.com";
// Rates
static long uploadRate = 51200; // Bits per second, minimum 51200
static long downloadRate = 102400; // Bits per second, minimum 102400
UpdateBandwidthRateLimitResult updateBandwidthRateLimitResult =
sgClient.updateBandwidthRateLimit(updateBandwidthRateLimitRequest);
String returnGatewayARN = updateBandwidthRateLimitResult.getGatewa
yARN();
System.out.println("Updated the bandwidth rate limits of " + re
turnGatewayARN);
System.out.println("Upload bandwidth limit = " + uploadRate + "
bits per second");
System.out.println("Download bandwidth limit = " + downloadRate +
" bits per second");
}
catch (AmazonClientException ex)
{
System.err.println("Error updating gateway bandwith.\n" + ex.to
String());
}
}
}
Example : Updating Gateway Bandwidth Limits by Using the AWS SDK for .NET
The following C# code example updates a gateway's bandwidth rate limits. You need to update the code
and provide the service endpoint, your gateway Amazon Resource Name (ARN), and the upload and
download limits. For a list of AWS service endpoints you can use with AWS Storage Gateway, see Regions
and Endpoints in the AWS General Reference.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Amazon.StorageGateway;
using Amazon.StorageGateway.Model;
namespace AWSStorageGateway
{
class UpdateBandwidthExample
{
static AmazonStorageGatewayClient sgClient;
static AmazonStorageGatewayConfig sgConfig;
// The gatewayARN
public static String gatewayARN = "*** provide gateway ARN ***";
// The endpoint
static String serviceURL = "https://storagegateway.us-east-1.amazon
aws.com";
// Rates
static long uploadRate = 51200; // Bits per second, minimum 51200
static long downloadRate = 102400; // Bits per second, minimum 102400
UpdateBandwidthRateLimitResponse updateBandwidthRateLimitResponse
= sgClient.UpdateBandwidthRateLimit(updateBandwidthRateLimitRequest);
String returnGatewayARN = updateBandwidthRateLimitResponse.Up
dateBandwidthRateLimitResult.GatewayARN;
Console.WriteLine("Updated the bandwidth rate limits of " +
returnGatewayARN);
Console.WriteLine("Upload bandwidth limit = " + uploadRate + "
bits per second");
Console.WriteLine("Download bandwidth limit = " + downloadRate
+ " bits per second");
}
catch (AmazonStorageGatewayException ex)
{
Console.WriteLine("Error updating gateway bandwith.\n" +
ex.ToString());
}
}
}
}
Example : Updating Gateway Bandwidth Limits by Using the AWS Tools for Windows
PowerShell
The following PowerShell script example updates a gateway's bandwidth rate limits. You need to update
the script and provide your gateway Amazon Resource Name (ARN), and the upload and download limits.
<#
.DESCRIPTION
Update Gateway bandwidth limits.
.NOTES
PREREQUISITES:
1) AWS Tools for PowerShell from http://aws.amazon.com/powershell/
2) Credentials and region stored in session using Initialize-AWSDefault.
For more info see, http://docs.aws.amazon.com/powershell/latest/userguide/spe
cifying-your-aws-credentials.html
.EXAMPLE
powershell.exe .\SG_UpdateBandwidth.ps1
#>
$UploadBandwidthRate = 51200
$DownloadBandwidthRate = 102400
$gatewayARN = "*** provide gateway ARN ***"
You can choose to let AWS Storage Gateway apply updates according to the maintenance schedule for
your gateway, or you can apply the updates yourself. When you deploy and activate your gateway, a
default weekly maintenance schedule is set. You can modify this schedule at any time by choosing edit
time next to Maintenance Start Time on the Gateway tab of the console.
The following example shows the Gateway tab with a maintenance message and the Apply Update
Now button. The date and time the last successful software update was applied to the gateway appears
in the Gateway tab.
Important
A software update forces your gateway to restart your gateway. You can minimize the chance
of any disruption to your applications by increasing your iSCSI initiators’ timeouts. For more
information about increasing iSCSI initiator timeouts for Windows and Linux, see Customizing
Your Windows iSCSI Settings (p. 147) and Customizing Your Linux iSCSI Settings (p. 151).
Topics
• Logging In to Your AWS Storage Gateway Local Console (p. 262)
• Routing Your On-Premises Gateway Through a Proxy (p. 267)
• Configuring Your Gateway Network (p. 268)
• Testing Your Gateway Connection to the Internet (p. 271)
• Synchronizing Your Gateway VM Time (p. 272)
• Running Storage Gateway Commands on the Local Console (p. 274)
• Viewing Your Gateway System Resource Status (p. 275)
• Configuring Network Adapters for Your Gateway (p. 276)
• Creating a Volume on a Gateway with Multiple Network Adapters (p. 285)
In this topic, we show you how to access the local console of a gateway hosted in these hypervisors:
• VMware ESXi—for more information, see To access your gateway's local console (VMware ESXi) (p. 263).
• Microsoft Hyper-V—for more information, see To access your gateway's local console (Microsoft
Hyper-V) (p. 264).
Note
If your gateway VM is turned on, a green arrow icon appears with the VM icon, as shown
in the following screenshot. If your gateway VM is not turned on, you can turn it on by
choosing the green Power On icon on the Toolbar menu.
5. To log in using the default credentials, continue to the procedure Logging in to the Local Console
Using Default Credentials (p. 265).
1. In the Virtual Machines list of the Microsoft Hyper-V Manager, select your gateway VM.
2. Ensure the gateway is turned on.
Note
If your gateway VM is turned on, Running is displayed as the State of the VM, as shown
in the following screenshot. If your gateway VM is not turned on, you can turn it on by
choosing Start in the Actions pane.
The Virtual Machine Connection window appears. If an authentication window appears, type the
user name and password provided to you by the hypervisor administrator.
5. To log in default credentials, continue to the procedure Logging in to the Local Console Using Default
Credentials (p. 265).
• If this is your first time logging in to the local console, log in to the VM with the user name sguser
and password sgpassword. Otherwise, use your credentials to log in.
After you log in, you see the Storage Gateway Configuration main menu, as shown in the following
screenshot.
Note
We recommend changing the default password. You do this by running the passwd command
from the Gateway Console menu (item 5 on the main menu). For information about how to run
the command, see Running Storage Gateway Commands on the Local Console (p. 274). You
can also set your own password from the AWS Storage Gateway console. For more information,
see Setting the Local Console Password from the Storage Gateway Console (p. 266).
To See
Configure a SOCKS proxy for your gateway Routing Your On-Premises Gateway Through a
Proxy (p. 267).
Run Storage Gateway console commands Running Storage Gateway Commands on the Local
Console (p. 274).
4. In the Set Local Console Password dialog box, type a new password and choose Set Local
Console Password. Your new password replaces the default password. AWS Storage Gateway
does not save the password but rather safely transmits it to the VM.
Note
The password can consist of any character on the keyboard and can be 1 to 512 characters
long.
1. Log in to your gateway's local console. For instructions, see Logging In to Your AWS Storage Gateway
Local Console (p. 262).
2. On the AWS Storage Gateway Configuration main menu, type 1 to begin configuring the SOCKS
proxy.
3. Choose one of the following options on the AWS Storage Gateway SOCKS Proxy Configuration
menu:
To Do This
1. Log in to your gateway's local console. For instructions, see Logging In to Your AWS Storage Gateway
Local Console (p. 262).
2. On the AWS Storage Gateway Configuration main menu, type option 2 to begin configuring a static
IP address.
3. Choose one of the following options on the AWS Storage Gateway Network Configuration menu:
To Do This
To Do This
Important
If your gateway has already been activ-
ated, you must shut it down and restart it
from the AWS Storage Gateway console
for the settings to take effect. For more in-
formation, see Shutting Down and Starting
Your Gateway (p. 251).
To Do This
Important
If your gateway has already been activ-
ated, you must shut down and restart your
gateway from the AWS Storage Gateway
console for the settings to take effect. For
more information, see Shutting Down and
Starting Your Gateway (p. 251).
1. Log in to your gateway's local console. For instructions, see Logging In to Your AWS Storage Gateway
Local Console (p. 262).
2. On the AWS Storage Gateway Configuration main menu, type option 3 to begin testing network
connectivity.
Each endpoint in the selected region displays either a PASSED or FAILED message, as shown
following.
Message Description
For information about network and firewall requirements, see Network and Firewall Requirements (p. 14).
For a gateway deployed on VMware ESXi, setting the hypervisor host time and synchronizing the VM
time to the host is sufficient to avoid time drift. For more information, see Step 2.2.3: Synchronize VM
Time with Host Time (p. 23). For a gateway deployed on Microsoft Hyper-V, you should periodically check
your VM's time using the procedure described following.
1. Log in to your gateway's local console. For instructions, see Logging In to Your AWS Storage Gateway
Local Console (p. 262).
2. On the AWS Storage Gateway Configuration main menu, type 4 for System Time Management.
3. On the System Time Management menu, type 1 for View and Synchronize System Time.
4. If the result indicates that you should synchronize your VM's time to the Network Time Protocol (NTP)
time, type y. Otherwise, type n.
The following screenshot shows a VM that does not require time synchronization.
1. Log in to your gateway's local console. For instructions, see Logging In to Your AWS Storage Gateway
Local Console (p. 262).
2. On the AWS Storage Gateway Configuration main menu, type option 5 for Gateway Console.
3. On the AWS Storage Gateway console, type h, and then press the Return key.
The console displays the Available Commands menu with the available commands and after the
menu a Gateway Console prompt, as shown in the following screenshot.
4. To learn about a command, type man + command name at the Gateway Console prompt.
1. Log in to your gateway's local console. For instructions, see Logging In to Your AWS Storage Gateway
Local Console (p. 262).
2. In the AWS Storage Gateway Configuration main menu, type 6 to view the results of a system
resource check.
The console displays an [OK], [WARNING], or [FAIL] message for each resource as described in
the table following.
Message Description
The console also displays the number of errors and warnings next to the resource check menu option.
The following screenshot shows a [FAIL] message and the accompanying error message.
Gateway so it can be accessed by more than one IP address. You do this by configuring your gateway
to use more than one network adapter.
Topics
• Configuring Your Gateway to Use the VMXNET3 Network Adapter (p. 277)
• Configuring Your Gateway for Multiple NICs (p. 279)
Following are the steps you take to configure your gateway to use the VMXNET3 adapter:
To remove the default E1000 adapter and configure your gateway to use the VMXNET3
adapter
1. In VMware, open the context (right-click) menu for your gateway and choose Edit Settings.
2. In the Virtual Machine Properties window, choose the Hardware tab.
3. For Hardware, choose Network adapter. Notice that the current adapter is E1000 in the Adapter
Type section. You will replace this adapter with the VMXNET3 adapter.
4. Choose the E1000 network adapter, and then choose Remove. In this example, the E1000 network
adapter is Network adapter 1.
Note
Although you can run the E1000 and VMXNET3 network adapters in your gateway at the
same time, we don't recommend doing so because it can cause network problems.
5. Choose Add to open the Add Hardware wizard.
6. Choose Ethernet Adapter, and then choose Next.
7. In the Network Type wizard, select VMXNET3 for Adapter Type, and then choose Next.
8. In the Virtual Machine properties wizard, verify in the Adapter Type section that Current Adapter
is set to VMXNET3, and then choose OK.
9. In the VMware VSphere client, shut down your gateway.
10. In the VMware VSphere client, restart your gateway.
After your gateway restarts, reconfigure the adapter you just added to make sure that network connectivity
to the Internet is established.
1. In the VSphere client, choose the Console tab to start the local console. You will use the default
login credentials to log in to the gateway's local console for this configuration task. For information
about how to log in using the default credentials, see Logging in to the Local Console Using Default
Credentials (p. 265).
2. At the prompt, type 2 to select Network Configuration, and then press Enter to open the network
configuration menu.
3. At the prompt, type 4 to select Reset to DHCP, and then type y (for yes) at the prompt to reset the
adapter you just added to use Dynamic Host Configuration Protocol (DHCP). You can type 5 to set
all adapters to DHCP.
4. At the Enter the adapter prompt, type eth0, and then press Enter to continue. The only adapter
available is eth0.
If your gateway is already activated, you must shut it down and restart it from the AWS Storage
Gateway Management Console. After the gateway restarts, you must test network connectivity to
the Internet. For information about how to test network connectivity, see Testing Your Gateway
Connection to the Internet (p. 271).
• Maximizing throughput – You might want to maximize throughput to a gateway when network adapters
are a bottleneck.
• Application separation – You might need to separate how your applications write to a gateway's
volumes. For example, you might choose to have a critical storage application exclusively use one
particular adapter defined for your gateway.
• Network constraints – Your application environment might require that you keep your iSCSI targets
and the initiators that connect to them in an isolated network that is different from the network by which
the gateway communicates with AWS.
In a typical multiple-adapter use case, one adapter is configured as the route by which the gateway
communicates with AWS (that is, as the default gateway). Except for this one adapter, initiators must be
in the same subnet as the adapter that contains the iSCSI targets to which they connect. Otherwise,
communication with the intended targets might not be possible. If a target is configured on the same
adapter that is used for communication with AWS, then iSCSI traffic for that target and AWS traffic will
flow through the same adapter.
The following procedure assumes that your gateway VM already has one network adapter defined and
that you are adding a second adapter. The first procedure shows how to add an adapter for VMware
ESXi, and the second shows how for Microsoft Hyper-V.
1. Shut down the gateway. For instructions, see To shut down a gateway (p. 252).
2. In the VMware vSphere client, select your gateway VM.
4. On the Hardware tab of the Virtual Machine Properties dialog box, choose Add to add a device.
a. In the Device Type pane, choose Ethernet Adapter to add an adapter, and then choose Next.
b. In the Network Type pane, ensure that Connect at power on is selected for Type, and then
choose Next.
We recommend that you use the E1000 network adapter with Storage Gateway. For more
information on the adapter types that might appear in the adapter list, go to Network Adapter
Types in the ESXi and vCenter Server Documentation.
c. In the Ready to Complete pane, review the information, and then choose Finish.
6. Choose the Summary tab of the VM, and choose View All next to the IP Address box. A Virtual
Machine IP Addresses window displays all the IP addresses you can use to access the gateway.
Confirm that a second IP address is listed for the gateway.
Note
It might take several moments for the adapter changes to take effect and the VM summary
information to refresh.
The following image is for illustration only. In practice, one of the IP addresses will be the address
by which the gateway communicates to AWS and the other will be an address in a different subnet.
7. On the Storage Gateway console, turn on the gateway. For instructions, see To start a gateway (p. 252).
8. In the Navigation pane of the Storage Gateway console, choose the gateway to which you added
the adapter, and then choose the Gateway tab.
1. On the Storage Gateway console, turn off the gateway. For instructions, see To shut down a
gateway (p. 252).
2. In the Microsoft Hyper-V Manager, select your gateway VM.
3. If the VM isn't turned off already, open the context (right-click) menu for your gateway and choose
Turn Off.
4. In the client, open the context menu for your gateway VM and choose Settings.
5. In the Settings dialog box for the VM, for Hardware, choose Add Hardware.
6. In the Add Hardware pane, choose Network Adapter, and then choose Add to add a device.
7. Configure the network adapter, and then choose Apply to apply settings.
In the following example, Virtual Network 2 is selected for the new adapter.
8. In the Settings dialog box, for Hardware, confirm that the second adapter was added, and then
choose OK.
9. On the Storage Gateway console, turn on the gateway. For instructions, see To start a gateway (p. 252).
10. In the Navigation pane of the Storage Gateway console, select the gateway to which you added the
adapter, and then choose the Gateway tab.
Note that the Create Storage Volume dialog box displays a drop-down list for Host IP, with one IP
address per adapter configured for the gateway VM. If the gateway VM is configured for only one
network adapter, a drop-down list does not appear because there is only one IP address.
To create a connection to the storage volume, see Connecting to Volumes on Your Volume
Gateway (p. 145).
Topics
• Logging In to Your Amazon EC2 Gateway Local Console (p. 287)
• Routing Your Gateway Deployed on Amazon EC2 Through a Proxy (p. 287)
• Testing Your Gateway Connectivity to the Internet (p. 289)
• Running Storage Gateway Commands on the Local Console (p. 290)
• Viewing Your Gateway System Resource Status (p. 291)
1. Log in to your local console. If you are connecting from a Windows computer, log in as sguser.
2. After you log in, you see the AWS Storage Gateway Configuration main menu, as shown in the
following screenshot.
To See
Configure a SOCKS proxy for your gateway Routing Your Gateway Deployed on Amazon EC2
Through a Proxy (p. 287)
Run Storage Gateway console commands Running Storage Gateway Commands on the Local
Console (p. 290)
View a system resource check Logging In to Your Amazon EC2 Gateway Local
Console (p. 287).
If your gateway must use a proxy server to communicate to the Internet, then you need to configure the
SOCKS proxy settings for your gateway. You do this by specifying an IP address and port number for
the host running your proxy. After you do so, AWS Storage Gateway will route all HyperText Transfer
Protocol Secure (HTTPS) traffic through your proxy server.
1. Log in to your gateway's local console. For instructions, see Logging In to Your Amazon EC2 Gateway
Local Console (p. 287).
2. On the AWS Storage Gateway Configuration main menu, type 1 to begin configuring the SOCKS
proxy.
3. Choose one of the following options in the AWS Storage Gateway SOCKS Proxy Configuration
menu:
To Do This
1. Log in to your gateway's local console. For instructions, see Logging In to Your Amazon EC2 Gateway
Local Console (p. 287).
2. In the AWS Storage Gateway Configuration main menu, type 2 to begin testing network connectivity.
Each endpoint in the region you select displays either a [PASSED] or [FAILED] message, as shown
following.
Message Description
1. Log in to your gateway's local console. For instructions, see Logging In to Your Amazon EC2 Gateway
Local Console (p. 287).
2. In the AWS Storage Gateway Configuration main menu, type 3 for Gateway Console.
3. In the Storage Gateway console, type h, and then press the Return key.
The console displays the Available Commands menu with the available commands. After the menu,
a Gateway Console prompt appears, as shown in the following screenshot.
4. To learn about a command, type man + command name at the Gateway Console prompt.
1. Log in to your gateway's local console. For instructions, see Logging In to Your Amazon EC2 Gateway
Local Console (p. 287).
2. In the AWS Storage Gateway Configuration main menu, type 4 to view the results of a system
resource check.
The console displays an [OK], [WARNING], or [FAIL] message for each resource as described in
the table following.
Message Description
Message Description
The console also displays the number of errors and warnings next to the resource check menu option.
The following screenshot shows a [FAIL] message and the accompanying error message.
You can also launch an instance by using the 1-Click Launch feature in AWS Marketplace. In this case,
an autogenerated security group that is named AWS Storage Gateway-1-0-AutogenByAWSMP- is
created. This security group has the correct rule for port 80 to activate your gateway. For more information
about security groups, go to Security Group Concepts in the Amazon EC2 User Guide for Linux Instances.
Regardless of the security group that you use, we recommend the following:
• The security group should not allow incoming connections from the outside Internet. It should allow
only instances within the gateway security group to communicate with the gateway. If you need to allow
instances to connect to the gateway from outside its security group, we recommend you allow
connections only on ports 3260 (for iSCSI connections) and 80 (for activation).
• If you want to activate your gateway from an EC2 host outside the gateway security group, allow
incoming connections on port 80 from the IP address of that host. If you cannot determine the activating
host's IP address, you can open port 80, activate your gateway, and then close access on port 80 after
completing activation.
• Allow port 22 access only if you are using AWS Support for troubleshooting purposes. For more
information, see Enabling AWS Support to Access a Gateway Hosted on an Amazon EC2
Instance (p. 302).
If you are using an Amazon EC2 instance as an initiator (that is, to connect to the iSCSI targets on the
gateway you deployed on Amazon EC2), then we recommend a two-step approach:
1. You should launch the initiator instance in the same security group as the gateway.
2. You should configure access so the initiator can communicate with the gateway.
When you delete a gateway, it no longer appears on the AWS Storage Gateway Management Console
and its iSCSI connection to the initiator is closed. The procedure for deleting a gateway is the same for
all gateway types; however, depending on the type of gateway you want to delete and the host it is
deployed on, you follow specific instructions to remove associated resources.
You can delete a gateway using the Storage Gateway console or programmatically. You can find
information following about how to delete a gateway using the Storage Gateway console. If you want to
programmatically delete your gateway, see AWS Storage Gateway API Reference.
Topics
• Deleting Your Gateway by Using the AWS Storage Gateway Console (p. 293)
• Removing Resources from a Gateway Deployed On-Premises (p. 294)
• Removing Resources from a Gateway Deployed on an Amazon EC2 Instance (p. 296)
To delete a gateway
4. In the dialog box that appears, select I want to permanently delete the selected gateway. Take
note of the gateway name that is displayed in the dialog box to make sure you have selected the
gateway you intend to delete. In this example, the gateway named ExampleGateway will be deleted.
Warning
When a gateway is deleted, there is no way to get it back.
Important
You no longer pay software charges after you delete a gateway, but resources such as virtual
tapes, Amazon Elastic Block Store (Amazon EBS) snapshots, and Amazon EC2 instances
persist. You will continue to be billed for these resources. You can choose to remove Amazon
EC2 instances and Amazon EBS snapshots by canceling your Amazon EC2 subscription. If you
want to keep your Amazon EC2 subscription, you can delete your Amazon EBS snapshots using
the Amazon EC2 console.
• Delete the gateway. For instructions, see Deleting Your Gateway by Using the AWS Storage Gateway
Console (p. 293).
• Delete all Amazon EBS snapshots you don't need. For instructions, go to Deleting an Amazon EBS
Snapshot in the Amazon EC2 User Guide for Linux Instances.
If the gateway-VTL you want to delete is deployed on a virtual machine (VM), we suggest that you take
the following actions to clean up resources.
Important
Before you delete a gateway-VTL, you must cancel all tape retrieval operations and eject all
retrieved tapes.
After you have deleted the gateway-VTL, you must remove any resources associated with the
gateway-VTL that you don't need to avoid paying for those resources.
When you delete a gateway-VTL, you can encounter one of two scenarios.
• The gateway-VTL is connected to AWS – If the gateway-VTL is connected to AWS and you delete
the gateway, the iSCSI targets associated with the gateway (that is, the virtual tape drives and media
changer) will no longer be available.
• The gateway-VTL is not connected to AWS – If the gateway-VTL is not connected to AWS, for
example if the underlying VM is turned off or your network is down, then you cannot delete the gateway.
If you attempt to do so, after your environment is back up and running you might have a gateway-VTL
running on-premises with available iSCSI targets. However, no gateway-VTL data will be uploaded to,
or downloaded from, AWS.
If the gateway-VTL you want to delete is not functioning, you must first disable it and delete tapes that
have the RETRIEVING or RETRIEVED status before you delete the gateway-VTL, as described following:
• For instructions on disabling a gateway-VTL, see Disabling Your Gateway-VTL (p. 312).
• To delete tapes that have the RETRIEVING status from the library, cancel the retrieval process. For
instructions, see Canceling Tape Retrieval (p. 179).
• To delete tapes that have the RETRIEVED status from the library, eject the tape using your backup
software. For instructions, see Archiving the Tape (p. 122).
After disabling the gateway-VTL and deleting tapes, you can delete the gateway-VTL. For instructions
on how to delete a gateway, see Deleting Your Gateway by Using the AWS Storage Gateway
Console (p. 293).
If you have tapes archived in a virtual tape shelf (VTS), those tapes remain and you continue to pay for
storage until you delete them. For instruction on how to delete tapes from a VTS. see Deleting Tapes
from Your VTS (p. 182).
Important
You are charged for a minimum of 90 days storage for virtual tapes in a VTS. If you retrieve a
virtual tape that has been stored in the VTS for less than 90 days, you are still charged for 90
days storage.
1. In the Storage Gateway console, delete the gateway as shown in Deleting Your Gateway by Using the
AWS Storage Gateway Console (p. 293).
2. In the Amazon EC2 console, stop your EC2 instance if you plan on using the instance again. Otherwise,
terminate the instance. If you plan on deleting volumes, make note of the block devices that are attached
to the instance and the devices' identifiers before terminating the instance. You will need these to
identify the volumes you want to delete.
3. In the Amazon EC2 console, remove all Amazon EBS volumes that are attached to the instance if you
don't plan on using them again. For more information, see Clean Up Your Instance and Volume in the
Amazon EC2 User Guide for Linux Instances.
1. Delete all virtual tapes that have RETRIEVING status from the gateway-VTL. For more information,
see Canceling Tape Retrieval (p. 179).
2. Delete all virtual tapes that you have retrieved to your gateway-VTL. For more information, see Deleting
Tapes from Your Gateway-VTL (p. 177).
3. Delete all virtual tapes from the tape library. For more information, see Deleting Tapes from Your
Gateway-VTL (p. 177).
4. Delete the gateway-VTL. For more information, see Deleting Your Gateway by Using the AWS Storage
Gateway Console (p. 293).
5. Terminate all Amazon EC2 instances, and delete all Amazon EBS volumes. For more information, see
Clean Up Your Instance and Volume in the Amazon EC2 User Guide for Linux Instances.
6. Delete all archived virtual tapes from the virtual tape shelf (VTS). For more information, see Deleting
Tapes from Your VTS (p. 182).
Important
You are charged for a minimum of 90 days storage for virtual tapes in a VTS. If you retrieve
a virtual tape that has been stored in the VTS for less than 90 days, you are still charged for
90 days storage.
Topics
• Troubleshooting On-Premises Gateway Issues (p. 297)
• Enabling AWS Support Access to Your Gateway Hosted On-Premises (p. 299)
• Troubleshooting Amazon EC2 Gateway Issues (p. 300)
• Troubleshooting Volume, Snapshot, and Tape Issues (p. 304)
You cannot find the IP ad- Use the hypervisor client to connect to your host to find the gateway IP
dress of your gateway. address.
• For VMware ESXi, the VM's IP address can be found in the vSphere
client on the Summary tab. For more information, see Step 2.4: Ac-
tivate the AWS Storage Gateway (p. 33).
• For Microsoft Hyper-V, the VM's IP address can be found by logging
into the local console. For more information, see Step 2.4: Activate
Your Storage Gateway (p. 53).
• Check that the VM is turned on. Only when the VM is turned on does
an IP address get assigned to your gateway.
• Wait for the VM to finish startup. If you just turned on your VM, then
it might take several minutes for the gateway to finish its boot se-
quence.
You're having network or fire- • Allow the appropriate ports for your gateway.
wall problems. • If you use a firewall or router to filter or limit network traffic, you must
configure your firewall and router to allow these service endpoints for
outbound communication to AWS. For more information about network
and firewall requirements, see Network and Firewall Require-
ments (p. 14).
Your gateway's activation fails • Check that the gateway VM can be accessed by pinging the VM from
when you click the Proceed your client.
to Activation button in the • Check that your VM has network connectivity to the Internet. Other-
AWS Storage Gateway con- wise, you'll need to configure a SOCKS proxy. For more information
sole. on doing so, see Routing Your On-Premises Gateway Through a
Proxy (p. 267).
• Check that the host has the correct time, that the host is configured
to synchronize its time automatically to a Network Time Protocol (NTP)
server, and that the gateway VM has the correct time. For information
about synchronizing the time of hypervisor hosts and VMs, see Syn-
chronizing Your Gateway VM Time (p. 272).
• After performing these steps, you can retry the gateway deployment
using the AWS Storage Gateway console and the Setup and Activate
Gateway wizard.
• Check that your VM has at least 7.5 GB of RAM. Gateway allocation
fails if there is less than 7.5 GB of RAM. For more information, see
Requirements (p. 12).
You need to remove a disk For instructions about removing a disk allocated as upload buffer space,
allocated as upload buffer see Removing Upload Buffer Capacity (p. 241)
space. For example, you
might want to reduce the
amount of upload buffer
space for a gateway, or you
might need to replace a disk
used as an upload buffer that
has failed.
You need to improve band- You can improve the bandwidth from your gateway to AWS by setting
width between your gateway up your Internet connection to AWS on a network adapter (NIC) separate
and AWS. from that connecting your applications and the gateway VM. Taking this
approach is useful if you have a high-bandwidth connection to AWS and
you want to avoid bandwidth contention, especially during a snapshot
restore. For high-throughput workload needs, you can use AWS Direct
Connect to establish a dedicated network connection between your on-
premises gateway and AWS. To measure the bandwidth of the connec-
tion from your gateway to AWS, use the CloudBytesDownloaded and
CloudBytesUploaded metrics of the gateway. For more on this subject,
see Measuring Performance Between Your Gateway and AWS (p. 219).
Improving your Internet connectivity helps to ensure that your upload
buffer does not fill up.
Throughput to or from your • On the Gateway tab of the AWS Storage Gateway console, verify
gateway drops to zero. that the IP addresses for your gateway VM are the same that you see
using your hypervisor client software (that is, the VMware Vsphere
client or Microsoft Hyper-V Manager). If you find a mismatch, restart
your gateway from the AWS Storage Gateway console, as shown in
Shutting Down and Starting Your Gateway (p. 251). After the restart,
the addresses in the IP Addresses list in the AWS Storage Gateway
console's Gateway tab should match the IP addresses for your
gateway, which you determine from the hypervisor client.
• For VMware ESXi, the VM's IP address can be found in the vSphere
client on the Summary tab. For more information, see Step 2.4:
Activate the AWS Storage Gateway (p. 33).
• For Microsoft Hyper-V, the VM's IP address can be found by logging
into the local console. For more information, see Step 2.4: Activate
Your Storage Gateway (p. 53).
• Check your gateway's connectivity to AWS as described in Testing
Your Gateway Connection to the Internet (p. 271).
• Check your gateway's network adapter configuration, and ensure that
all the interfaces you intended to be enabled for the gateway are en-
abled. To view the network adapter configuration for your gateway,
follow the instructions in Configuring Your Gateway Network (p. 268)
and select the option for viewing your gateway's network configuration.
You can view the throughput to and from your gateway from the Amazon
CloudWatch console. For more information about measuring throughput
to and from your gateway to AWS, see Measuring Performance Between
Your Gateway and AWS (p. 219).
You are having trouble import- See Troubleshooting Your Microsoft Hyper-V Setup (p. 376), which dis-
ing (deploying) AWS Storage cusses some of the common issues of deploying a gateway on Microsoft
Gateway on Microsoft Hyper- Hyper-V.
V.
1. Log in to your host's local console. For instructions, go to Logging Into Your Gateway Local Console.
Once the support channel is established, provide the support service number you chose to AWS
Support so AWS Support can provide troubleshooting assistance.
For more information about enabling AWS Support to access a gateway hosted on an EC2 instance, see
the following section Enabling AWS Support to Access a Gateway Hosted on an Amazon EC2
Instance (p. 302).
Your Amazon EC2 gateway If activation has not occurred in a few moments, check the following in
activation fails when you click the Amazon EC2 console:
the Proceed to Activation
button in the AWS Storage • Port 80 is enabled in the security group you associated with the in-
Gateway console. stance. For more information about adding a security group rule, go
to Adding a Security Group Rule in the Amazon EC2 User Guide for
Linux Instances.
• The gateway instance is marked as running. In the Amazon EC2
console, the State of the instance should be RUNNING.
After correcting the problem, try activating the gateway again by going
to the AWS Storage Gateway console, clicking Deploy a new Gateway
on Amazon EC2, and re-entering the IP address of the instance.
You can't find your Amazon If you did not give your instance a resource tag and you have many in-
EC2 gateway instance in the stances running, it can be hard to tell which instance you deployed the
list of instances. gateway in. In this case, you can take the following actions to find the
gateway instance:
• Check the name of the Amazon Machine Image (AMI) name on the
Description tab of the instance. An instance based on the AWS
Storage Gateway AMI should start with the text aws-storage-
gateway-ami.
• If you have several instances based on the AWS Storage Gateway
AMI, check the instance launch time to find the correct instance.
You created an Amazon EBS Check that the Amazon EBS volume in question is in the same Availab-
volume but can't attach it to ility Zone as the gateway instance. If there is a discrepancy in Availability
your Amazon EC2 gateway Zones, create a new Amazon EBS volume in the same Availability Zone
instance. as your instance.
You can't attach an initiator to Check that the security group you launched the instance with includes
a volume target of your a rule allowing the port that you are using for iSCSI access. The port is
Amazon EC2 gateway. usually set as 3260. For more information on connecting to volumes,
see Connecting to Volumes on Your Volume Gateway (p. 145).
You activated your Amazon For a newly activated gateway, no volume storage is defined. Before
EC2 gateway, but when you you can define volume storage, you must allocate local disks to the
try to add storage volumes, gateway to use as an upload buffer and cache storage. For a gateway
you receive an error message deployed to Amazon EC2, the local disks are Amazon EBS volumes
indicating you have no disks attached to the instance. This error message likely occurs because no
available. Amazon EBS volumes are defined for the instance.
Check block devices defined for the instance that is running the gateway.
If there are only two block devices (the default devices that come with
the AMI), then you should add storage. For more information on doing
so, see Amazon EC2 Gateway (p. 60). After attaching two or more
Amazon EBS volumes, try creating volume storage on the gateway.
You need to remove a disk Follow the steps in Adding and Removing Upload Buffer Capacity for
allocated as upload buffer Your Gateway (p. 241).
space because you want to
reduce the amount of upload
buffer space.
Throughput to or from your • Verify the gateway instance is running. If the instance is starting due
Amazon EC2 gateway drops to a reboot, for example, wait for the instance to restart.
to zero. • Verify that the gateway IP has not changed. If the instance was
stopped and then restarted, the IP address of the instance might have
changed. In this case, you need to activate a new gateway.
You can view the throughput to and from your gateway from the Amazon
CloudWatch console. For more information about measuring throughput
to and from your gateway to AWS, see Measuring Performance Between
Your Gateway and AWS (p. 219).
Warning
The elastic IP address of the Amazon EC2 instance cannot be used as the target address.
To let AWS Support connect to your gateway, you first log in to the local console for the Amazon EC2
instance, navigate to the storage gateway's console, and then provide the access.
1. Log in to the local console for your Amazon EC2 instance. For instructions, go to Connect to Your
Instancein the Amazon EC2 User Guide.
You can use the following command to log in to the EC2 instance's local console.
Note
The PRIVATE-KEY is the .pem file containing the private certificate of the EC2 key pair that
you used to launch the Amazon EC2 instance. For more information, go to Retrieving the
Public Key for Your Key Pair in the Amazon EC2 User Guide.
The INSTANCE-PUBLIC-DNS-NAME is the public Domain Name System (DNS) name of
your Amazon EC2 instance that your gateway is running on. You obtain this public DNS
name by selecting the Amazon EC2 instance in the EC2 console and clicking the Description
tab.
Once the support channel is established, provide the support service number you selected to AWS
Support so they can provide troubleshooting assistance.
Topics
• Troubleshooting Volume Issues (p. 304)
• Troubleshooting Snapshot Issues (p. 307)
• Troubleshooting Virtual Tape Issues (p. 308)
Topics
• The Console Says That Your Volume Is Not Configured (p. 304)
• The Console Says That Your Volume Is Irrecoverable (p. 304)
• The Console Says That Your Volume Has PASS THROUGH Status (p. 305)
• You Want to Verify Volume Integrity and Fix Possible Errors (p. 305)
• Your Volume's iSCSI Target Doesn’t Appear in Windows Disk Management Console (p. 305)
• You Want to Change Your Volume's iSCSI Target Name (p. 305)
• Your Scheduled Volume Snapshot Did Not Occur (p. 305)
• You Need to Remove or Replace a Volume (p. 306)
• Throughput from Your Application to a Volume Has Dropped to Zero (p. 306)
• A Cache Disk in Your Gateway Encounters a Failure (p. 306)
If deleting the volume in the AWS Storage Gateway console does not work, then the disk allocated for
the volume might have been improperly removed from the VM and cannot be removed from the appliance.
The Console Says That Your Volume Has PASS THROUGH Status
In some cases, the AWS Storage Gateway console might indicate that your volume has a status of PASS
THROUGH (p. 172). A volume can have PASS THROUGH (p. 172) status for several reasons. Some
reasons require action, and some do not.
An example of when you should take action if your volume has the PASS THROUGH status is when your
gateway has run out of upload buffer space. To verify if your upload buffer was exceeded in the past, you
can view the UploadBufferPercentUsed metric in the Amazon CloudWatch console; for more
information, see Monitoring the Upload Buffer (p. 225). If your gateway has the PASS THROUGH status
because it has run out of upload buffer space, you should allocate more upload buffer space to your
gateway. Adding more buffer space will cause your volume to transition from PASS THROUGH to
BOOTSTRAPPING (p. 172) to AVAILABLE (p. 172) automatically. While the volume has the
BOOTSTRAPPING status, the gateway reads data off the volume's disk, uploads this data to Amazon
S3, and catches up as needed. When the gateway has caught up and saved the volume data to Amazon
S3, the volume status becomes AVAILABLE and snapshots can be started again. Note that when your
volume has the PASS THROUGH or BOOTSTRAPPING status, you can continue to read and write data
from the volume disk. For more information about adding more upload buffer space, see Managing the
Upload Buffer (p. 238).
To take action before the upload buffer is exceeded, you can set a threshold alarm on a gateway's upload
buffer. For more information, see To set an upper threshold alarm for a gateway's upload buffer (p. 226).
In contrast, an example of not needing to take action when a volume has the PASS THROUGH status
is when the volume is waiting to be bootstrapped because another volume is currently being bootstrapped.
The gateway bootstraps volumes one at a time.
Infrequently, the PASS THROUGH status can indicate that a disk allocated for an upload buffer has failed.
In this is the case, you should remove the disk. For more information, see Removing Upload Buffer
Capacity (p. 241)
console and create an alarm for this metric. For more information, see Monitoring the Upload Buffer (p. 225)
and To set an upper threshold alarm for a gateway's upload buffer (p. 226).
• For VMware ESXi, remove the backing storage as described in To remove the underlying local disk
(VMware ESXi) (p. 167).
• For Microsoft Hyper-V, remove the backing storage as described in To remove the underlying local
disk (Microsoft Hyper-V) (p. 168).
• If you are using the VMware vSphere client, check that your volume's Host IP address matches one
of the addresses that appears in the vSphere client on the Summary tab. You can find the Host IP
address for a storage volume in the AWS Storage Gateway console in the ISCSI Target Info tab for
the volume. A discrepancy in the IP address can occur, for example, when you assign a new static IP
address to your gateway. If there is a discrepancy, restart your gateway from the AWS Storage Gateway
console as shown in Shutting Down and Starting Your Gateway (p. 251). After the restart, the Host IP
address in the ISCSI Target Info tab for a storage volume should match an IP address shown in the
vSphere client on the Summary tab for the gateway.
• Check to see if IPAddressNotFound appears in the Host IP box for the volume. For example, this
message can appear when you create a volume associated with an IP address of a network adapter
of a gateway with two or more network adapters. When you remove or disable the network adapter
that the volume is associated with, the IPAddressNotFound message is displayed. To address this
issue, delete the volume and then re-create it preserving its existing data. For more information, see
Managing Volumes (p. 161).
• Check that the iSCSI initiator your application uses is correctly mapped to the iSCSI target for the
storage volume. For more information about connecting to storage volumes, see Connecting to Volumes
on Your Volume Gateway (p. 145).
You can view the throughput for volumes and create alarms from the Amazon CloudWatch console. For
more information about measuring throughput from your application to a volume, see Measuring
Performance Between Your Application and Gateway (p. 218).
• If the cache disk is inaccessible or unusable, delete the disk from your gateway configuration.
• If the cache disk is still accessible and useable, reconnect it to your gateway.
Note
If you delete a cache disk, tapes or volumes that have clean data (that is, for which data in the
cache disk and Amazon S3 are synchronized) will continue to be available when the gateway
resumes normal functionality. For example, if your gateway has three cache disks and you delete
two, tapes or volumes that are clean will have AVAILABLE status. Other tapes and volumes will
have IRRECOVERABLE status.
If you use ephemeral disks as cache disks for your gateway or mount your cache disks on an
ephemeral drive, your cache disks will be lost when you shut down the gateway. Shutting down
the gateway when your cache disk and Amazon S3 are not synchronized can result in data loss.
As a result, we don't recommend using ephemeral drives or disks.
Topics
• A Volume Snapshot Has PENDING Status Longer Than Expected (p. 307)
• Using Recovery Snapshots for Your Gateway-Cached Setup (p. 307)
If any of these situations is the case, we recommend that you delete the snapshot. For more information,
see Deleting a Snapshot (p. 196). When the volume returns to AVAILABLE (p. 172) status, create a new
snapshot of the volume.
Volume recovery points are maintained automatically for each gateway-cached volume. You can also
take snapshots on a one-time, ad hoc basis or set up a snapshot schedule for the volume. For more
information about snapshots, see Working with Snapshots (p. 184).
When the gateway becomes unreachable (such as when you shut it down), you have the option of creating
a snapshot from a volume recovery point.
6. Find the snapshot using the steps in the procedure Finding a Snapshot (p. 186).
7. Restore the snapshot using one of the procedures in Restoring a Snapshot (p. 211).
Topics
• Recovering a Virtual Tape (p. 309)
• Troubleshooting Irrecoverable Tapes (p. 311)
• Disabling Your Gateway-VTL (p. 312)
Topics
• You Need to Recover a Virtual Tape from a Malfunctioning Gateway-VTL (p. 309)
• You Need to Recover a Virtual Tape from a Malfunctioning Cache Disk (p. 310)
If your gateway-VTL or the hypervisor host encounters an unrecoverable failure, you can recover the
tapes from that gateway-VTL to another gateway-VTL.
AWS Storage Gateway periodically takes point-in-time snapshots of all the tapes in the library. These
snapshots are called recovery points. You can recover tapes to another gateway-VTL from the latest
recovery point. To recover tapes from a failed gateway-VTL to another gateway-VTL, use the following
procedure.
1. Identify an existing functioning gateway-VTL to serve as your recovery target gateway. If you don't
have a gateway-VTL to recover your tapes to, deploy and activate a new gateway-VTL. For information
on how to deploy and activate a gateway, see Step 2: Deploy a VM and Activate the Gateway (p. 17).
2. Open the AWS Storage Gateway console at https://console.aws.amazon.com/storagegateway/.
3. Choose the gateway-VTL you want to disable. All virtual tapes associated with the gateway-VTL are
displayed.
4. Disable the failed gateway. This process permanently halts normal function of your gateway-VTL
and exposes any available recovery points. For instructions, see Disabling Your Gateway-VTL (p. 312).
5. From the tapes that the disabled gateway displays, choose the virtual tape and the recovery point
you want to recover. A virtual tape can have multiple recovery points.
6. To begin recovering any tapes you need to the target gateway-VTL, choose Create Recovery Tape.
7. In the Create Recovery Tape dialog box, verify the barcode of the virtual tape you want to recover.
8. For Gateway, choose the gateway-VTL you want to recover the virtual tape to.
9. Choose Create Recovery Tape.
10. Delete the failed gateway-VTL so you don't get charged. For instructions, see Deleting Your Gateway
by Using the AWS Storage Gateway Console and Removing Associated Resources (p. 293).
Storage Gateway moves the tape from the failed gateway-VTL to the gateway-VTL you specified. The
gateway-VTL marks the tape status as RECOVERED.
If your cache disk encounters a error, the gateway prevents read and write operations on virtual tapes in
the gateway. For example, an error can occur when a disk is corrupted or removed from the gateway.
The AWS Storage Gateway console displays a message about the error, as shown following.
In the error message, Storage Gateway prompts you to take one of two actions that can recover your
tapes:
• Shut Down and Re-Add Disks – Take this approach if the disk has intact data and has been removed.
For example, if the error occurred because a disk was removed from your host by accident but the disk
and the data is intact, you can re-add the disk. To do this, see the procedure later in this topic.
• Reset Cache Disk – Take this approach if the cache disk is corrupted or not accessible. If the disk
error causes the cache disk to be inaccessible, unusable, or corrupted, you can reset the disk. If you
reset the cache disk, tapes that have clean data (that is, tapes for which data in the cache disk and
Amazon S3 are synchronized) will continue to be available for you to use. However, tapes that have
data that is not synchronized with Amazon S3 are automatically recovered. The status of these tapes
is set to RECOVERED, but the tapes will be read-only. For information about how to remove a disk
from your host, see Adding and Removing Upload Buffer Capacity for Your Gateway (p. 241).
Important
If the cache disk you are resetting contains data that has not been uploaded to Amazon S3
yet, that data can be lost. After you reset cache disks, no configured cache disks will be left
in the gateway, so you must configure at least one new cache disk for your gateway to function
properly.
To reset the cache disk, see the procedure later in this topic.
1. Shut down the gateway. For information about how to shut down a gateway, see Shutting Down and
Starting Your Gateway (p. 251).
2. Add the disk back to your host, and make sure the disk node number of the disk has not changed.
For information about how to add a disk, see Adding and Removing Upload Buffer Capacity for Your
Gateway (p. 241).
3. Restart the gateway. For information about how to restart a gateway, see Shutting Down and Starting
Your Gateway (p. 251).
After the gateway restarts, you can verify the status of the cache disks. The status of a disk can be one
of the following:
1. In the A disk error has occurred error message illustrated preceding, choose Reset Cache Disk.
2. On the Configure Your Activated Gateway page, configure the disk for cache storage. For
information about how to do so, see Step 2: Configure Local Storage and Alarms
(Gateway-VTL) (p. 104).
3. After you have configured cache storage, shut down and restart the gateway as described in the
previous procedure.
The gateway should recover after the restart. You can then verify the status of the cache disk.
The following screenshot shows an example of the Configure Your Activated Gateway page. In this
example, the status of the cache disk node xen-vbd-2288 is missing.
Note
If you do not complete the recovery process, the gateway displays a banner that prompts you
to configure local storage.
If you have a virtual tape with the status IRRECOVERABLE, and you need to work with it, try one of the
following:
• Activate a new gateway-VTL if you don't have one activated. For more information, see Step 2: Deploy
a VM and Activate the Gateway (p. 17).
• Disable the gateway-VTL that contains the irrecoverable tape, and recover the tape from a recovery
point to the new gateway-VTL. For more information, see You Need to Recover a Virtual Tape from a
Malfunctioning Gateway-VTL (p. 309).
Note
You have to reconfigure your iSCSI initiator and backup application to use the new
gateway-VTL. For more information, see Step 4: Connect Your Gateway-VTL Devices to Your
Windows Client (p. 108).
You Don't Need an IRRECOVERABLE Tape That Is Archived to VTS and Retrieved to
Gateway-VTL
Suppose you have a virtual tape with the status IRRECOVERABLE, you don't need it, and the tape has
previously been archived to VTS and retrieved to your gateway-VTL. In this case, use your backup
software to archive the tape in VTS. For more information, see Archiving Tapes to the VTS (p. 178).
If you have a virtual tape with the status IRRECOVERABLE, you don't need it, and the tape has never
been archived to VTS, you should delete the tape. For more information, see Deleting Tapes from Your
Gateway-VTL (p. 177).
If one or more cache disks in your gateway encounters a failure, the gateway prevents read and write
operations to your virtual tapes and volumes. To resume normal functionality, reconfigure your gateway
as described following:
• If the cache disk is inaccessible or unusable, delete the disk from your gateway configuration.
• If the cache disk is still accessible and useable, reconnect it to your gateway.
Note
If you delete a cache disk, tapes or volumes that have clean data (that is, for which data in the
cache disk and Amazon S3 are synchronized) will continue to be available when the gateway
resumes normal functionality. For example, if your gateway has three cache disks and you delete
two, tapes or volumes that are clean will have AVAILABLE status. Other tapes and volumes will
have IRRECOVERABLE status.
If you use ephemeral disks as cache disks for your gateway or mount your cache disks on an
ephemeral drive, your cache disks will be lost when you shut down the gateway. Shutting down
the gateway when your cache disk and Amazon S3 are not synchronized can result in data loss.
As a result, we don't recommend using ephemeral drives or disks.
Note that you can only disable a gateway on the Storage Gateway console if the gateway is no longer
connected to AWS. If the gateway is connected to AWS, you don't see the Disable Gateway button in
the console.
Access to AWS Storage Gateway requires credentials that AWS can use to authenticate your requests.
Those credentials must have permissions to access AWS resources, such as a gateway, volume, or tape.
The following sections provide details on how you can use AWS Identity and Access Management (IAM)
and AWS Storage Gateway to help secure your resources by controlling who can access them:
Authentication
You can access AWS as any of the following types of identities:
• AWS account root user – When you sign up for AWS, you provide an email address and password
that is associated with your AWS account. These are your root credentials and they provide complete
access to all of your AWS resources.
Important
For security reasons, we recommend that you use the root credentials only to create an
administrator user, which is an IAM user with full permissions to your AWS account. Then,
you can use this administrator user to create other IAM users and roles with limited permissions.
For more information, see IAM Best Practices and Creating an Admin User and Group in the
IAM User Guide.
• IAM user – An IAM user is simply an identity within your AWS account that has specific custom
permissions (for example, permissions to create a gateway in AWS Storage Gateway). You can use
an IAM user name and password to sign in to secure AWS webpages like the AWS Management
Console, AWS Discussion Forums, or the AWS Support Center.
In addition to a user name and password, you can also generate access keys for each user. You can
use these keys when you access AWS services programmatically, either through one of the several
SDKs or by using the AWS Command Line Interface (CLI). The SDK and CLI tools use the access
keys to cryptographically sign your request. If you don’t use the AWS tools, you must sign the request
yourself. AWS Storage Gateway supports Signature Version 4, a protocol for authenticating inbound
API requests. For more information about authenticating requests, see Signature Version 4 Signing
Process in the AWS General Reference.
• IAM role – An IAM role is another IAM identity you can create in your account that has specific
permissions. It is similar to an IAM user, but it is not associated with a specific person. An IAM role
enables you to obtain temporary access keys that can be used to access AWS services and resources.
IAM roles with temporary credentials are useful in the following situations:
• Federated user access – Instead of creating an IAM user, you can use preexisting user identities
from AWS Directory Service, your enterprise user directory, or a web identity provider. These are
known as federated users. AWS assigns a role to a federated user when access is requested through
an identity provider. For more information about federated users, see Federated Users and Roles in
the IAM User Guide.
• Cross-account access – You can use an IAM role in your account to grant another AWS account
permissions to access your account’s resources. For an example, see Tutorial: Delegate Access
Across AWS Accounts Using IAM Roles in the IAM User Guide.
• AWS service access – You can use an IAM role in your account to grant an AWS service permissions
to access your account’s resources. For example, you can create a role that allows Amazon Redshift
to access an Amazon S3 bucket on your behalf and then load data stored in the bucket into an
Amazon Redshift cluster. For more information, see Creating a Role to Delegate Permissions to an
AWS Service in the IAM User Guide.
• Applications running on Amazon EC2 – Instead of storing access keys within the EC2 instance
for use by applications running on the instance and making AWS API requests, you can use an IAM
role to manage temporary credentials for these applications. To assign an AWS role to an EC2
instance and make it available to all of its applications, you can create an instance profile that is
attached to the instance. An instance profile contains the role and enables programs running on the
EC2 instance to get temporary credentials. For more information, see Using Roles for Applications
on Amazon EC2 in the IAM User Guide.
Access Control
You can have valid credentials to authenticate your requests, but unless you have permissions you cannot
create or access AWS Storage Gateway resources. For example, you must have permissions to create
a gateway in AWS Storage Gateway.
The following sections describe how to manage permissions for AWS Storage Gateway. We recommend
that you read the overview first.
• Overview of Managing Access Permissions to Your AWS Storage Gateway (p. 316)
• Identity-Based Policies (IAM Policies) (p. 317)
When granting permissions, you decide who is getting the permissions, the resources they get permissions
for, and the specific actions that you want to allow on those resources.
Topics
• AWS Storage Gateway Resources and Operations (p. 316)
• Understanding Resource Ownership (p. 317)
• Managing Access to Resources (p. 317)
• Specifying Policy Elements: Actions, Effects, Resources, and Principals (p. 318)
• Specifying Conditions in a Policy (p. 319)
These resources and subresources have unique Amazon Resource Names (ARNs) associated with them
as shown in the following table.
Gateway arn:aws:storagegateway:region:account-id:gateway/gateway-id
ARN
Note
• AWS Storage Gateway resource IDs are in uppercase. When you use these resource IDs
with the Amazon EC2 API, Amazon EC2 expects resource IDs in lowercase.You must change
your resource ID to lowercase to use it with the EC2 API. For example, in Storage Gateway
the ID for a volume might be vol-1122AABB. When you use this ID with the EC2 API, you
must change it to vol-1122aabb. Otherwise, the EC2 API might not behave as expected.
• ARNs for gateways activated prior to September 2, 2015, contain the gateway name instead
of the gateway ID. To obtain the ARN for your gateway, use the
DescribeGatewayInformation API operation.
To grant permissions for specific API operations, such as creating a tape, AWS Storage Gateway provides
a set of API actions for you to create and manage these resources and subresources. For a list of API
actions, see Actions in the AWS Storage Gateway API Reference.
To grant permissions for specific API operations, such as creating a tape, AWS Storage Gateway defines
a set of actions that you can specify in a permissions policy to grant permissions for specific API operations.
An API operation can require permissions for more than one action. For a table showing all the AWS
Storage Gateway API actions and the resources they apply to, see AWS Storage Gateway API Permissions:
Actions, Resources, and Conditions Reference (p. 326).
• If you use the root account credentials of your AWS account to activate a gateway, your AWS account
is the owner of the resource (in AWS Storage Gateway, the resource is the gateway).
• If you create an IAM user in your AWS account and grant permissions to the ActivateGateway action
to that user, the user can activate a gateway. However, your AWS account, to which the user belongs,
owns the gateway resource.
• If you create an IAM role in your AWS account with permissions to activate a gateway, anyone who
can assume the role can activate a gateway. Your AWS account, to which the role belongs, owns the
gateway resource.
Policies attached to an IAM identity are referred to as identity-based policies (IAM polices) and policies
attached to a resource are referred to as resource-based policies. AWS Storage Gateway supports only
identity-based policies (IAM policies).
Topics
• Identity-Based Policies (IAM Policies) (p. 317)
• Resource-Based Policies (p. 318)
• Attach a permissions policy to a user or a group in your account – An account administrator can
use a permissions policy that is associated with a particular user to grant permissions for that user to
create an AWS Storage Gateway resource, such as a gateway, volume, or tape.
• Attach a permissions policy to a role (grant cross-account permissions) – You can attach an
identity-based permissions policy to an IAM role to grant cross-account permissions. For example, the
administrator in Account A can create a role to grant cross-account permissions to another AWS account
(for example, Account B) or an AWS service as follows:
1. Account A administrator creates an IAM role and attaches a permissions policy to the role that grants
permissions on resources in Account A.
2. Account A administrator attaches a trust policy to the role identifying Account B as the principal who
can assume the role.
3. Account B administrator can then delegate permissions to assume the role to any users in Account
B. Doing this allows users in Account B to create or access resources in Account A. The principal
in the trust policy can also be an AWS service principal if you want to grant an AWS service
permissions to assume the role.
For more information about using IAM to delegate permissions, see Access Management in the IAM
User Guide.
The following is an example policy that grants permissions to all List* actions on all resources. This
action is a read-only action. Thus, the policy doesn't allow the user to change the state of the resources.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAllListActionsOnAllResources",
"Effect": "Allow",
"Action": [
"storagegateway:List*"
],
"Resource": "*"
}
]
}
For more information about using identity-based policies with AWS Storage Gateway, see Using
Identity-Based Policies (IAM Policies) for AWS Storage Gateway (p. 319). For more information about
users, groups, roles, and permissions, see Identities (Users, Groups, and Roles in the IAM User Guide.
Resource-Based Policies
Other services, such as Amazon S3, also support resource-based permissions policies. For example,
you can attach a policy to an S3 bucket to manage access permissions to that bucket. AWS Storage
Gateway doesn't support resource-based policies.
• Resource – In a policy, you use an Amazon Resource Name (ARN) to identify the resource to which
the policy applies. For AWS Storage Gateway resources, you always use the wildcard character (*)
in IAM policies. For more information, see AWS Storage Gateway Resources and Operations (p. 316).
• Action – You use action keywords to identify resource operations that you want to allow or deny. For
example, depending on the specified Effect, the storagegateway:ActivateGateway permission
allows or denies the user permissions to perform the AWS Storage Gateway ActivateGateway
operation.
• Effect – You specify the effect when the user requests the specific action—this can be either allow or
deny. If you don't explicitly grant access to (allow) a resource, access is implicitly denied. You can also
explicitly deny access to a resource, which you might do to make sure that a user cannot access it,
even if a different policy grants access.
• Principal – In identity-based policies (IAM policies), the user that the policy is attached to is the implicit
principal. For resource-based policies, you specify the user, account, service, or other entity that you
want to receive permissions (applies to resource-based policies only). AWS Storage Gateway doesn't
support resource-based policies.
To learn more about IAM policy syntax and descriptions, see AWS IAM Policy Reference in the IAM User
Guide.
For a table showing all of the AWS Storage Gateway API actions, see AWS Storage Gateway API
Permissions: Actions, Resources, and Conditions Reference (p. 326).
To express conditions, you use predefined condition keys. There are no condition keys specific to Storage
Gateway. However, there are AWS-wide condition keys that you can use as appropriate. For a complete
list of AWS-wide keys, see Available Keys in the IAM User Guide.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowsSpecifiedActionsOnAllGateways",
"Effect": "Allow",
"Action": [
"storagegateway:ActivateGateway",
"storagegateway:ListGateways"
],
"Resource": "arn:aws:storagegateway:us-west-2:account-id:gateway/*"
},
{
"Sid": "AllowsSpecifiedEC2ActionsOnAllGateways",
"Effect": "Allow",
"Action": [
"ec2:DescribeSnapshots",
"ec2:DeleteSnapshot"
],
"Resource": "*"
}
]
}
The policy has two statements (note the Action and Resource elements in both the statements):
• The first statement grants permissions for two Storage Gateway actions
(storagegateway:ActivateGateway and storagegateway:ListGateways) on a gateway
resource using the Amazon Resource Name (ARN) for the gateway. The ARN specifies a wildcard
character (*) because you don't know the gateway ID until after you create a gateway.
Note
ARNs uniquely identify AWS resources. For more information, see Amazon Resource Names
(ARNs) and AWS Service Namespaces in the AWS General Reference.
The wildcard character (*) at the end of the gateway ARN means that this statement can match any
gateway ID. In this case, the statement allows the storagegateway:ActivateGateway and
storagegateway:ListGateways actions on any gateway in the specified region, us-west-2, and
the specified ID identifies the account that is owner of the gateway resource. For information about
how to use a wildcard character (*) in a policy, see Example 2: Allow Read-Only Access to a
Gateway (p. 322).
To limit permissions for a particular action to a specific gateway only, create a separate statement for
that action in the policy and specify the gateway ID in that statement.
Because these Amazon EC2 actions don't support resource-level permissions, the policy specifies the
wildcard character (*) as the Resource value instead of specifying a gateway ARN.
For a table showing all of the AWS Storage Gateway API actions and the resources that they apply to,
see AWS Storage Gateway API Permissions: Actions, Resources, and Conditions Reference (p. 326).
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowsSpecifiedEC2ActionOnAllGateways",
"Effect": "Allow",
"Action": [
"ec2:DescribeSnapshots"
],
"Resource": "*"
}
]
}
This additional permission is required because the Amazon EBS snapshots generated from AWS Storage
Gateway are managed as Amazon EC2 resources.
To set up the minimum permissions required to navigate the Storage Gateway console, see Example 2:
Allow Read-Only Access to a Gateway (p. 322).
The following AWS managed policies, which you can attach to users in your account, are specific to
Storage Gateway:
Note
You can review these permissions policies by signing in to the IAM console and searching for
specific policies there.
You can also create your own custom IAM policies to allow permissions for AWS Storage Gateway API
actions. You can attach these custom policies to the IAM users or groups that require those permissions.
Topics
• Example 1: Allow Any AWS Storage Gateway Actions on All Gateways (p. 322)
• Example 2: Allow Read-Only Access to a Gateway (p. 322)
• Example 3: Allow Access to a Specific Gateway (p. 323)
• Example 4: Allow a User to Access a Specific Volume (p. 325)
• Example 5: Allow All Actions on Gateways with a Specific Prefix (p. 326)
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowsAllAWSStorageGatewayActions",
"Action": [
"storagegateway:*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "AllowsSpecifiedEC2Actions",
"Action": [
"ec2:DescribeSnapshots",
"ec2:DeleteSnapshot"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
The policy also allows the DescribeSnapshots Amazon EC2 action. For more information, see
DescribeSnapshots in the Amazon EC2 API Reference.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadOnlyAccessToAllGateways",
"Action": [
"storagegateway:List*",
"storagegateway:Describe*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "AllowsUserToDescribeSnapshotsOnAllGateways",
"Action": [
"ec2:DescribeSnapshots"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
In the preceding policy, instead of a using a wildcard character (*), you can scope resources covered by
the policy to a specific gateway, as shown in the following example. The policy then allows the actions
only on the specific gateway.
"Resource": [
"arn:aws:storagegateway:us-west-2:123456789012:gateway/gateway-
id/",
"arn:aws:storagegateway:us-west-2:123456789012:gateway/gateway-
id/*"
]
Within a gateway, you can further restrict the scope of the resources to only the gateway volumes, as
shown in the following example:
"Resource": "arn:aws:storagegateway:us-west-2:123456789012:gateway/gateway-
id/volume/*"
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadOnlyAccessToAllGateways",
"Action": [
"storagegateway:List*",
"storagegateway:Describe*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "AllowsUserToDescribeSnapshotsOnAllGateways",
"Action": [
"ec2:DescribeSnapshots"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "AllowsAllActionsOnSpecificGateway",
"Action": [
"storagegateway:*"
],
"Effect": "Allow",
"Resource": [
"arn:aws:storagegateway:us-west-2:123456789012:gateway/gateway-
id/",
"arn:aws:storagegateway:us-west-2:123456789012:gateway/gateway-
id/*"
]
}
]
}
The preceding policy works if the user to which the policy is attached uses either the API or an AWS SDK
to access the gateway. However, if the user is going to use the AWS Storage Gateway console, you must
also grant permissions to allow the ListGateways action, as shown in the following example:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowsAllActionsOnSpecificGateway",
"Action": [
"storagegateway:*"
],
"Effect": "Allow",
"Resource": [
"arn:aws:storagegateway:us-west-2:123456789012:gateway/gateway-
id/",
"arn:aws:storagegateway:us-west-2:123456789012:gateway/gateway-
id/*"
]
},
{
"Sid": "AllowsUserToUseAWSConsole",
"Action": [
"storagegateway:ListGateways"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GrantsPermissionsToSpecificVolume",
"Action": [
"storagegateway:*"
],
"Effect": "Allow",
"Resource": "arn:aws:storagegateway:us-west-2:123456789012:gate
way/gateway-id/volume/volume-id"
},
{
"Sid": "GrantsPermissionsToUseStorageGatewayConsole",
"Action": [
"storagegateway:ListGateways"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
The preceding policy works if the user to whom the policy is attached uses either the API or an AWS SDK
to access the volume. However, if this user is going to use the AWS Storage Gateway console, you must
also grant permissions to allow the ListGateways action, as shown in the following example:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GrantsPermissionsToSpecificVolume",
"Action": [
"storagegateway:*"
],
"Effect": "Allow",
"Resource": "arn:aws:storagegateway:us-west-2:123456789012:gate
way/gateway-id/volume/volume-id"
},
{
"Sid": "GrantsPermissionsToUseStorageGatewayConsole",
"Action": [
"storagegateway:ListGateways"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowsActionsGatewayWithPrefixDeptX",
"Action": [
"storagegateway:*"
],
"Effect": "Allow",
"Resource": "arn:aws:storagegateway:us-west-2:123456789012:gate
way/DeptX"
},
{
"Sid": "GrantsPermissionsToSpecifiedAction",
"Action": [
"ec2:DescribeSnapshots"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
The preceding policy works if the user to whom the policy is attached uses either the API or an AWS SDK
to access the gateway. However, if this user plans to use the AWS Storage Gateway console, you must
grant additional permissions as described in Example 3: Allow Access to a Specific Gateway (p. 323).
You can use AWS-wide condition keys in your AWS Storage Gateway policies to express conditions. For
a complete list of AWS-wide keys, see Available keys in the IAM User Guide.
Note
To specify an action, use the storagegateway: prefix followed by the API operation name (for
example, storagegateway:ActivateGateway). For each AWS Storage Gateway action, you
can specify a wildcard character (*) as the resource.
For a list of Storage Gateway resources with the ARN format, see AWS Storage Gateway Resources
and Operations (p. 316).
ActivateGateway
Action(s): storagegateway:ActivateGateway
Resource: *
AddCache
Action(s): storagegateway:AddCache
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
AddTagsToResource
Action(s): storagegateway:AddTagsToResource
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
or
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
or
arn:aws:storagegateway:region:account-id:tape/tapebarcode
AddUploadBuffer
Action(s): storagegateway:AddUploadBuffer
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
AddWorkingStorage
Action(s): storagegateway:AddWorkingStorage
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
CancelArchival
Action(s): storagegateway:CancelArchival
Resource: arn:aws:storagegateway:region:account-id:tape/tapebarcode
CancelRetrieval
Action(s): storagegateway:CancelRetrieval
Resource: arn:aws:storagegateway:region:account-id:tape/tapebarcode
CreateCachediSCSIVolume
Action(s): storagegateway:CreateCachediSCSIVolume
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
CreateSnapshot
Action(s): storagegateway:CreateSnapshot
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
CreateSnapshotFromVolumeRecoveryPoint
Action(s): storagegateway:CreateSnapshotFromVolumeRecoveryPoint
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
CreateStorediSCSIVolume
Action(s): storagegateway:CreateStorediSCSIVolume
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
CreateTapes
Action(s): storagegateway:CreateTapes
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DeleteBandwidthRateLimit
Action(s): storagegateway:DeleteBandwidthRateLimit
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DeleteChapCredentials
Action(s): storagegateway:DeleteChapCredentials
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/target/iSCSItarget
DeleteGateway
Action(s): storagegateway:DeleteGateway
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DeleteSnapshotSchedule
Action(s): storagegateway:DeleteSnapshotSchedule
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
DeleteTape
Action(s): storagegateway:DeleteTape
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DeleteTapeArchive
Action(s): storagegateway:DeleteTapeArchive
Resource: *
DeleteVolume
Action(s): storagegateway:DeleteVolume
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
DescribeBandwidthRateLimit
Action(s): storagegateway:DescribeBandwidthRateLimit
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DescribeCache
Action(s): storagegateway:DescribeCache
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DescribeCachediSCSIVolumes
Action(s): storagegateway:DescribeCachediSCSIVolumes
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
DescribeChapCredentials
Action(s): storagegateway:DescribeChapCredentials
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/target/iSCSItarget
DescribeGatewayInformation
Action(s): storagegateway:DescribeGatewayInformation
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DescribeMaintenanceStartTime
Action(s): storagegateway:DescribeMaintenanceStartTime
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DescribeSnapshotSchedule
Action(s): storagegateway:DescribeSnapshotSchedule
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
DescribeStorediSCSIVolumes
Action(s): storagegateway:DescribeStorediSCSIVolumes
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
DescribeTapeArchives
Action(s): storagegateway:DescribeTapeArchives
Resource: *
DescribeTapeRecoveryPoints
Action(s): storagegateway:DescribeTapeRecoveryPoints
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DescribeTapes
Action(s): storagegateway:DescribeTapes
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DescribeUploadBuffer
Action(s): storagegateway:DescribeUploadBuffer
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DescribeVTLDevices
Action(s): storagegateway:DescribeVTLDevices
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DescribeWorkingStorage
Action(s): storagegateway:DescribeWorkingStorage
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
DisableGateway
Action(s): storagegateway:DisableGateway
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
ListGateways
Action(s): storagegateway:ListGateways
Resource: *
ListLocalDisks
Action(s): storagegateway:ListLocalDisks
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
ListTagsForResource
Action(s): storagegateway:ListTagsForResource
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
or
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
or
arn:aws:storagegateway:region:account-id:tape/tapebarcode
ListVolumeInitiators
Action(s): storagegateway:ListVolumeInitiators
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
ListVolumeRecoveryPoints
Action(s): storagegateway:ListVolumeRecoveryPoints
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
ListVolumes
Action(s): storagegateway:ListVolumes
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
RemoveTagsFromResource
Action(s): storagegateway:RemoveTagsFromResource
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
or
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
or
arn:aws:storagegateway:region:account-id:tape/tapebarcode
ResetCache
Action(s): storagegateway:ResetCache
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
RetrieveTapeArchive
Action(s): storagegateway:RetrieveTapeArchive
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
RetrieveTapeRecoveryPoint
Action(s): storagegateway:RetrieveTapeRecoveryPoint
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
ShutdownGateway
Action(s): storagegateway:ShutdownGateway
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
StartGateway
Action(s): storagegateway:StartGateway
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
UpdateBandwidthRateLimit
Action(s): storagegateway:UpdateBandwidthRateLimit
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
UpdateChapCredentials
Action(s): storagegateway:UpdateChapCredentials
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/target/iSCSItarget
UpdateGatewayInformation
Action(s): storagegateway:UpdateGatewayInformation
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
UpdateGatewaySoftwareNow
Action(s): storagegateway:UpdateGatewaySoftwareNow
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
UpdateMaintenanceStartTime
Action(s): storagegateway:UpdateMaintenanceStartTime
Resource: arn:aws:storagegateway:region:account-id:gateway/gateway-id
UpdateSnapshotSchedule
Action(s): storagegateway:UpdateSnapshotSchedule
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/volume/volume-id
UpdateVTLDeviceType
Action(s): storagegateway:UpdateVTLDeviceType
Resource:
arn:aws:storagegateway:region:account-id:gateway/gateway-id/device/vtldevice
Related Topics
In addition to using the console, you can use the AWS Storage Gateway API to programmatically configure
and manage your gateways. This section describes the AWS Storage Gateway operations, request
signing for authentication and the error handling. For information about the regions and endpoints available
for AWS Storage Gateway, see Regions and Endpoints.
Note
You can also use the AWS SDKs when developing applications with AWS Storage Gateway.
The AWS SDKs for Java, .NET, and PHP wrap the underlying AWS Storage Gateway API,
simplifying your programming tasks. For information about downloading the SDK libraries, go
to Sample Code Libraries.
Topics
The following example shows headers that are used in the API_ActivateGateway operation.
POST / HTTP/1.1
Host: storagegateway.us-east-1.amazonaws.com
Content-Type: application/x-amz-json-1.1
The following are the headers that must include with your POST requests to AWS Storage Gateway.
Headers shown below that begin with "x-amz" are AWS-specific headers. All other headers listed are
common header used in HTTP transactions.
Header Description
Authorization The authorization header contains several of pieces of information about the
request that enable AWS Storage Gateway to determine if the request is a
valid action for the requester. The format of this header is as follows (line
breaks added for readability):
Authorization: AWS4-HMAC_SHA456
Credentials=YourAccessKey/yyymmdd/region/storagegate
way/aws4_request,
SignedHeaders=content-type;host;x-amz-date;x-amz-target,
Signature=CalculatedSignature
In the preceding syntax, you specify YourAccessKey, the year, month, and
day (yyyymmdd), the region, and the CalculatedSignature. The format of the
authorization header is dictated by the requirements of the AWS V4 Signing
process. The details of signing are discussed in the topic Signing Re-
quests (p. 334).
Content-Type: application/x-amz-json-1.1
Host Use the host header to specify the AWS Storage Gateway endpoint where
you send your request. For example, storagegateway.us-east-
1.amazonaws.com is the endpoint for the US East (N. Virginia) region. For
more information about the endpoints available for AWS Storage Gateway,
see Regions and Endpoints.
Host: storagegateway.region.amazonaws.com
x-amz-date You must provide the time stamp in either the HTTP Date header or the AWS
x-amz-date header. (Some HTTP client libraries don't let you set the Date
header.) When an x-amz-date header is present, the AWS Storage Gateway
ignores any Date header during the request authentication.The x-amz-date
format must be ISO8601 Basic in the YYYYMMDD'T'HHMMSS'Z' format. If
both the Date and x-amz-date header are used, the format of the Date
header does not have to be ISO8601.
x-amz-date: YYYYMMDD'T'HHMMSS'Z'
Header Description
x-amz-target This header specifies the version of the API and the operation that you are
requesting. The target header values are formed by concatenating the API
version with the API name and are in the following format.
x-amz-target: StorageGateway_APIversion.operationName
Signing Requests
AWS Storage Gateway requires that you authenticate every request you send by signing the request. To
sign a request, you calculate a digital signature using a cryptographic hash function. A cryptographic
hash is a function that returns a unique hash value based on the input. The input to the hash function
includes the text of your request and your secret access key. The hash function returns a hash value that
you include in the request as your signature. The signature is part of the Authorization header of your
request.
After receiving your request, AWS Storage Gateway recalculates the signature using the same hash
function and input that you used to sign the request. If the resulting signature matches the signature in
the request, AWS Storage Gateway processes the request. Otherwise, the request is rejected.
AWS Storage Gateway supports authentication using AWS Signature Version 4.The process for calculating
a signature can be broken into three tasks:
Rearrange your HTTP request into a canonical format. Using a canonical form is necessary because
AWS Storage Gateway uses the same canonical form when it recalculates a signature to compare with
the one you sent.
• Task 2: Create a String to Sign
Create a string that you will use as one of the input values to your cryptographic hash function. The
string, called the string to sign, is a concatenation of the name of the hash algorithm, the request date,
a credential scope string, and the canonicalized request from the previous task. The credential scope
string itself is a concatenation of date, region, and service information.
• Task 3: Create a Signature
Create a signature for your request by using a cryptographic hash function that accepts two input
strings: your string to sign and a derived key. The derived key is calculated by starting with your secret
access key and using the credential scope string to create a series of Hash-based Message
Authentication Codes (HMACs).
• The time stamp of the request is "Mon, 10 Sep 2012 00:00:00" GMT.
POST / HTTP/1.1
Host: storagegateway.us-east-1.amazonaws.com
x-amz-Date: 20120910T000000Z
Authorization: SignatureToBeCalculated
Content-type: application/x-amz-json-1.1
x-amz-target: StorageGateway_20120630.ListGateways
{}
The canonical form of the request calculated for Task 1: Create a Canonical Request (p. 334) is:
POST
/
content-type:application/x-amz-json-1.1
host:storagegateway.us-east-1.amazonaws.com
x-amz-date:20120910T000000Z
x-amz-target:StorageGateway_20120630.ListGateways
content-type;host;x-amz-date;x-amz-target
44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a
The last line of the canonical request is the hash of the request body. Also, note the empty third line in
the canonical request. This is because there are no query parameters for this API (or any AWS Storage
Gateway APIs).
The string to sign for Task 2: Create a String to Sign (p. 334) is:
AWS4-HMAC-SHA256
20120910T000000Z
20120910/us-east-1/storagegateway/aws4_request
92c0effa6f9224ac752ca179a04cecbede3038b0959666a8160ab452c9e51b3e
The first line of the string to sign is the algorithm, the second line is the time stamp, the third line is the
credential scope, and the last line is a hash of the canonical request from Task 1.
For Task 3: Create a Signature (p. 334), the derived key can be represented as:
6d4c40b8f2257534dbdca9f326f147a0a7a419b63aff349d9d9c737c9a0f4c81
The final step is to construct the Authorization header. For the demonstration access key
AKIAIOSFODNN7EXAMPLE, the header (with line breaks added for readability) is:
Error Responses
Topics
• Exceptions (p. 336)
• Operation Error Codes (p. 337)
• Error Responses (p. 355)
This section provides reference information about AWS Storage Gateway errors. These errors are
represented by an error exception and an operation error code. For example, the error exception
InvalidSignatureException is returned by any API response if there is a problem with the request
signature. However, the operation error code ActivationKeyInvalid is returned only for the
ActivateGateway API.
Depending on the type of error, AWS Storage Gateway may return only just an exception, or it may return
both an exception and an operation error code. Examples of error responses are shown in the Error
Responses (p. 355).
Exceptions
The following table lists AWS Storage Gateway API exceptions. When an AWS Storage Gateway operation
returns an error response, the response body contains one of these exceptions. The
InternalServerError and InvalidGatewayRequestException return one of the operation error
codes Operation Error Codes (p. 337) message codes that give the specific operation error code.
InternalFailure The request processing has failed due 500 Internal Server
to some unknown error, exception or Error
failure.
InternalServerError One of the operation error code mes- 500 Internal Server
sages Operation Error Codes (p. 337). Error
InvalidGatewayRequestExcep- One of the operation error code mes- 400 Bad Request
tion sages in Operation Error Codes (p. 337).
RequestExpired The request is past the expiration date 400 Bad Request
or the request date (either with 15 minute
padding), or the request date occurs
more than 15 minutes in the future.
ServiceUnavailable The request has failed due to a tempor- 503 Service Unavail-
ary failure of the server. able
SubscriptionRequiredExcep- The AWS Access Key Id needs a sub- 400 Bad Request
tion scription for the service.
UnrecognizedClientException The security token included in the re- 400 Bad Request
quest is invalid.
AddWorkingStorage
CreateStorediSCSIVolume
AddWorkingStorage
CreateStorediSCSIVolume
AddWorkingStorage
CreateCachediSCSIVolume
CreateSnapshot
CreateStorediSCSIVolume
CreateSnapshotFromVolumeRecov-
eryPoint
DeleteBandwidthRateLimit
DeleteChapCredentials
DeleteVolume
DescribeBandwidthRateLimit
DescribeCache
DescribeCachediSCSIVolumes
DescribeChapCredentials
DescribeGatewayInformation
DescribeMaintenanceStartTime
DescribeSnapshotSchedule
DescribeStorediSCSIVolumes
DescribeWorkingStorage
ListLocalDisks
ListVolumes
ListVolumeRecoveryPoints
ShutdownGateway
StartGateway
UpdateBandwidthRateLimit
UpdateChapCredentials
UpdateMaintenanceStartTime
UpdateGatewaySoftwareNow
UpdateSnapshotSchedule
AddWorkingStorage
CreateCachediSCSIVolume
CreateSnapshot
CreateStorediSCSIVolume
CreateSnapshotFromVolumeRecov-
eryPoint
DeleteBandwidthRateLimit
DeleteChapCredentials
DeleteVolume
DescribeBandwidthRateLimit
DescribeCache
DescribeCachediSCSIVolumes
DescribeChapCredentials
DescribeGatewayInformation
DescribeMaintenanceStartTime
DescribeSnapshotSchedule
DescribeStorediSCSIVolumes
DescribeWorkingStorage
ListLocalDisks
ListVolumes
ListVolumeRecoveryPoints
ShutdownGateway
StartGateway
UpdateBandwidthRateLimit
UpdateChapCredentials
UpdateMaintenanceStartTime
UpdateGatewaySoftwareNow
UpdateSnapshotSchedule
AddCache
AddUploadBuffer
AddWorkingStorage
CreateCachediSCSIVolume
CreateSnapshot
CreateSnapshotFromVolumeRecov-
eryPoint
CreateStorediSCSIVolume
DeleteBandwidthRateLimit
DeleteChapCredentials
DeleteGateway
DeleteVolume
DescribeBandwidthRateLimit
DescribeCache
DescribeCachediSCSIVolumes
DescribeChapCredentials
DescribeGatewayInformation
DescribeMaintenanceStartTime
DescribeSnapshotSchedule
DescribeStorediSCSIVolumes
DescribeWorkingStorage
ListLocalDisks
ListVolumes
ListVolumeRecoveryPoints
ShutdownGateway
StartGateway
UpdateBandwidthRateLimit
UpdateChapCredentials
UpdateMaintenanceStartTime
UpdateGatewaySoftwareNow
UpdateSnapshotSchedule
AddWorkingStorage
CreateCachediSCSIVolume
CreateSnapshot
CreateSnapshotFromVolumeRecov-
eryPoint
CreateStorediSCSIVolume
DeleteBandwidthRateLimit
DeleteChapCredentials
DeleteVolume
DescribeBandwidthRateLimit
DescribeCache
DescribeCachediSCSIVolumes
DescribeChapCredentials
DescribeGatewayInformation
DescribeMaintenanceStartTime
DescribeSnapshotSchedule
DescribeStorediSCSIVolumes
DescribeWorkingStorage
ListLocalDisks
ListVolumes
ListVolumeRecoveryPoints
ShutdownGateway
StartGateway
UpdateBandwidthRateLimit
UpdateChapCredentials
UpdateMaintenanceStartTime
UpdateGatewaySoftwareNow
UpdateSnapshotSchedule
ActivateGateway
AddCache
AddUploadBuffer
AddWorkingStorage
CreateCachediSCSIVolume
CreateSnapshot
CreateSnapshotFromVolumeRecov-
eryPoint
CreateStorediSCSIVolume
DeleteBandwidthRateLimit
DeleteChapCredentials
DeleteGateway
DeleteVolume
DescribeBandwidthRateLimit
DescribeCache
DescribeCachediSCSIVolumes
DescribeChapCredentials
DescribeGatewayInformation
DescribeMaintenanceStartTime
DescribeSnapshotSchedule
DescribeStorediSCSIVolumes
DescribeWorkingStorage
ListLocalDisks
ListGateways
ListVolumes
ListVolumeRecoveryPoints
ShutdownGateway
StartGateway
UpdateBandwidthRateLimit
UpdateChapCredentials
UpdateMaintenanceStartTime
UpdateGatewayInformation
UpdateGatewaySoftwareNow
UpdateSnapshotSchedule
ActivateGateway
AddCache
AddUploadBuffer
AddWorkingStorage
CreateCachediSCSIVolume
CreateSnapshot
CreateSnapshotFromVolumeRecov-
eryPoint
CreateStorediSCSIVolume
DeleteBandwidthRateLimit
DeleteChapCredentials
DeleteGateway
DeleteVolume
DescribeBandwidthRateLimit
DescribeCache
DescribeCachediSCSIVolumes
DescribeChapCredentials
DescribeGatewayInformation
DescribeMaintenanceStartTime
DescribeSnapshotSchedule
DescribeStorediSCSIVolumes
DescribeWorkingStorage
ListLocalDisks
ListGateways
ListVolumes
ListVolumeRecoveryPoints
ShutdownGateway
StartGateway
UpdateBandwidthRateLimit
UpdateChapCredentials
UpdateMaintenanceStartTime
UpdateGatewayInformation
UpdateGatewaySoftwareNow
UpdateSnapshotSchedule
AddWorkingStorage
DescribeCachediSCSIVolumes
DescribeStorediSCSIVolumes
ActivateGateway
AddCache
AddUploadBuffer
AddWorkingStorage
CreateCachediSCSIVolume
CreateSnapshot
CreateSnapshotFromVolumeRecov-
eryPoint
CreateStorediSCSIVolume
DeleteBandwidthRateLimit
DeleteChapCredentials
DeleteGateway
DeleteVolume
DescribeBandwidthRateLimit
DescribeCache
DescribeCachediSCSIVolumes
DescribeChapCredentials
DescribeGatewayInformation
DescribeMaintenanceStartTime
DescribeSnapshotSchedule
DescribeStorediSCSIVolumes
DescribeWorkingStorage
ListLocalDisks
ListGateways
ListVolumes
ListVolumeRecoveryPoints
ShutdownGateway
StartGateway
UpdateBandwidthRateLimit
UpdateChapCredentials
UpdateMaintenanceStartTime
UpdateGatewayInformation
UpdateGatewaySoftwareNow
UpdateSnapshotSchedule
CreateStorediSCSIVolume
DeleteChapCredentials
DescribeChapCredentials
UpdateChapCredentials
DeleteChapCredentials
DescribeChapCredentials
DeleteVolume
UpdateChapCredentials
CreateCachediSCSIVolume
CreateSnapshotFromVolumeRecov-
eryPoint
CreateStorediSCSIVolume
DeleteSnapshotSchedule
DescribeCache
DescribeCachediSCSIVolumes
DescribeStorediSCSIVolumes
DescribeUploadBuffer
DescribeWorkingStorage
ListVolumeRecoveryPoints
DeleteVolume
DescribeCachediSCSIVolumes
DescribeSnapshotSchedule
DescribeStorediSCSIVolumes
UpdateSnapshotSchedule
Error Responses
When there is an error, the response header information contains:
• Content-Type: application/x-amz-json-1.1
• An appropriate 4xx or 5xx HTTP status code
The body of an error response contains information about the error that occurred. The following sample
error response shows the output syntax of response elements common to all error responses.
{
"__type": "String",
"message": "String",
"error":
{ "errorCode": "String",
"errorDetails": "String"
}
}
The following table explains the JSON error response fields shown in the preceding syntax.
__type
One of the exceptions from Exceptions (p. 336).
Type: String
error
Contains API-specific error details. In general errors (i.e., not specific to any API), this error information
is not shown.
Type: Collection
errorCode
One of the operation error codes .
Type: String
errorDetails
This field is not used in the current version of the API.
Type: String
message
One of the operation error code messages.
Type: String
{
"__type": "InvalidGatewayRequestException",
"message": "The specified volume was not found.",
"error": {
"errorCode": "VolumeNotFound"
}
}
The following JSON body is returned if AWS Storage Gateway calculates a signature that does not match
the signature sent with a request.
{
"__type": "InvalidSignatureException",
"message": "The request signature we calculated does not match the signature
you provided."
}
You can find information following about AWS and third-party software, tools, and resources that can
help you set up or manage your gateway, and also about AWS Storage Gateway limits.
• Launching and Activating a Gateway's Amazon EC2 AMI in a Nondefault VPC (p. 357)
• Adding and Removing Amazon EBS Volumes for Your Gateway Hosted on Amazon EC2 (p. 358)
• Working with VTL Devices (p. 359)
• AWS Storage Gateway Limits (p. 362)
To launch and activate an Amazon EC2 gateway AMI into a nondefault VPC
1. Set up the VPC and Internet gateway. Take note of your VPC ID. For information about how to create
a VPC, go to Getting Started with Amazon VPC in the Amazon VPC Getting Started Guide.
A subnet and an Internet gateway are automatically created for your VPC. The subnet is associated
with the Internet gateway. A routing table is also created for your VPC and is associated with the
Internet gateway.
2. Create security group rules for your VPC. For more information, go to Step 3: Set Up a Security
Group for Your VPC in the Amazon VPC Getting Started Guide.
3. Create a network access control list (ACL) for your VPC:
• For inbound traffic, create a rule to allow port 80 (HTTP), and set the source to 0.0.0.0/0.
• For inbound traffic, next create a rule to allow ephemeral ports. For more information, go to
Ephemeral Ports in the Amazon VPC User Guide.
• For outbound traffic, create a rule to allow port 443 (HTTPS) and ports 1024–65535, set the
destination to 0.0.0.0/0, and then associate the ACL with your subnet.
For more information, go to Network ACLs in the Amazon VPC Getting Started Guide.
To See
Launch your gateway-VTL Step 2: Deploy and Activate a Gateway on Amazon EC2 (p. 61)
AMI into a VPC
Before you add more storage to the gateway, you should review how to size your upload buffer and cache
storage based on your application needs for a gateway. To do so, see Sizing the Upload Buffer (p. 240)
and Managing the Upload Buffer (p. 238).
There are limits to the maximum storage you can allocate as an upload buffer and cache storage. You
can attach as many Amazon EBS volumes to your instance as you want, but you can only configure these
volumes as upload buffer and cache storage space up to these storage limits. For more information, see
AWS Storage Gateway Limits (p. 362).
To create an Amazon EBS volume, attach it, and configure it for your gateway
1. Create an Amazon EBS volume. For instructions, go to Creating or Restoring an Amazon EBS
Volume in the Amazon EC2 User Guide for Linux Instances.
2. Attach the Amazon EBS volume to your Amazon EC2 instance. For instructions, go to Attaching an
Amazon EBS Volume to an Instance in the Amazon EC2 User Guide for Linux Instances.
3. Configure the Amazon EBS volume you added as either an upload buffer or cache storage. For
instructions, see Managing Local Storage for Your AWS Storage Gateway (p. 237).
There are times you might find you don’t need the amount of storage you allocated for the upload buffer.
1. Shut down the gateway by following the approach described in the Shutting Down and Starting Your
Gateway (p. 251) section.
2. Detach the Amazon EBS volume from your Amazon EC2 instance. For instructions, go to Detaching
an Amazon EBS Volume from an Instance in the Amazon EC2 User Guide for Linux Instances.
3. Delete the Amazon EBS volume. For instructions, go to Deleting an Amazon EBS Volume in the
Amazon EC2 User Guide for Linux Instances.
4. Start the gateway by following the approach described in the Shutting Down and Starting Your
Gateway (p. 251) section.
Topics
• Selecting a Medium Changer After Gateway Activation (p. 360)
• Updating the Device Driver for Your Medium Changer (p. 361)
For medium changers, AWS Storage Gateway works with the following:
Note
You must select the medium changer that is recommended for your backup software.
Other medium changers might not function properly.You can select a different medium
changer after the gateway is activated. For more information, see Selecting a Medium
Changer After Gateway Activation (p. 360).
For tape drives, AWS Storage Gateway works with the following:
1. Stop any related jobs that are running in your backup software.
2. On the Windows server, open the iSCSI initiator properties window.
3. Choose the Targets tab to display the discovered targets.
4. On the Discovered targets pane, choose the medium changer you want to change, choose
Disconnect, and then choose OK.
5. On the Navigation pane of the AWS Storage Gateway console, choose the gateway-VTL for which
you want to change the medium changer.
6. Choose the VTL Devices tab, and then choose the medium changer in the Tape Device ID column.
7. Choose the Details tab, and then choose the Configure Device Type link in the VTL Device Type
row.
8. On the Configure Device Type page, choose the Device Type box, select a medium changer, and
then choose Save.
1. Open Device Manager on your Windows server, and expand the Medium Changer devices tree.
2. Open the context (right-click) menu for Unknown Medium Changer, and choose Update Driver
Software to open the Update Driver Software-unknown Medium Changer window.
3.
In the How do you want to search for driver software? section, choose Browse my computer
for driver software.
4. Choose Let me pick from a list of device drivers on my computer.
Note
We recommend using the Sony TSL-A500C Autoloader driver with the Veeam Backup &
Replication V7, Veeam Backup & Replication V8, and Microsoft System Center 2012 R2
Data Protection Manager backup software. This Sony driver has been tested with these
types of backup software.
5. In the Select the device driver you want to install for this hardware section, clear the Show
compatible hardware check box, choose Sony in the Manufacturer list, choose Sony - TSL-A500C
Autoloader in the Model list, and then choose Next.
6. In the warning box that appears, choose Yes. If the driver is successfully installed, close the Update
drive software window.
Maximum number of 32 32 –
volumes for a gateway
Note
If you create a snapshot from a cached volume that is more than 16 TiB in size, you cannot
restore it to an Amazon Elastic Block Store (Amazon EBS) volume; however, it can be restored
to a Storage Gateway volume. For more information, see Restoring a Snapshot to an Amazon
EBS Volume (p. 214).
Note
The maximum upload rate was achieved by using 100 percent sequential write operations and
256 KB I/Os. Depending on your I/O mix and network conditions, the actual rate might be lower.
Third-Party Resources
• Components in Your VMware vSphere Environment for AWS Storage Gateway (p. 364)
• Configuring a VMware ESXi Host for AWS Storage Gateway (p. 365)
• Components in Your Hyper-V Environment for AWS Storage Gateway (p. 369)
• Configuring a Hyper-V Host for AWS Storage Gateway (p. 370)
• Adding and Removing Disks for Your Gateway (p. 380)
• Working with Open-Source Components for AWS Storage Gateway (p. 382)
• Using Symantec Backup Exec 2012 to Test Your Setup (p. 383)
The following table describes the subset of vSphere components that you typically work with when using
the AWS Storage Gateway service.
Component Description
VMware ESXi hypervisor OS (vSphere Server) The VMware server OS that hosts the gateway
virtual machine. You interact with the OS through
the vSphere client GUI. To provision a gateway in
AWS Storage Gateway, you only need to access
the host during the activation of the gateway. For
all other management and maintenance-related
functions, you use the AWS Management Console.
VMware vSphere Client (vSphere Client) The VMware software that you use on your com-
puter to access and manage your VMware environ-
ment. You manage your virtual machine (which
contains the gateway) using the client.
Component Description
Data store The storage on the vSphere server where the files
that define a virtual machine are stored. These files
come from the OVA file provided as part of the
service. When you deploy the OVA, you select a
data store on which to store the file, if there is more
than one data store for the VMware server.
The AWS Storage Gateway service includes an on-premises software appliance that communicates with
the AWS cloud storage infrastructure. The appliance is packaged as a virtual machine that you deploy
on a host running the VMware ESX/ESXi virtualization software. For more information on the VMware
virtualization software, go to VMware vSphere Hypervisor on the VMware website. For requirements that
your VMware environment must meet to run AWS Storage Gateway, see Requirements (p. 12).
Depending on your computer bios settings, the computer might automatically boot off your disk. If
not, check the relevant settings to boot the computer from the hypervisor disk.
3. Follow the instructions on the monitor to install the VMware hypervisor OS.
This installation wipes any existing content on the disk and installs the hypervisor.
Tip
After a successful VMware hypervisor host installation, the monitor displays the IP address
of the host computer. Note down this IP address. You use the IP address to connect to the
host.
4. Set the time on the host.
For instructions, see Step 2.2.3: Synchronize VM Time with Host Time (p. 23).
In the preceding steps, you provisioned a host with VMware hypervisor. The hypervisor is aware of host
computer configuration, such as available processors, memory, and local hard disks. The host provides
these resources to the AWS Storage Gateway.
You can optionally configure this host by adding more storage, such as additional direct-attached disks
or SAN disks. The following steps illustrate how you can add one or more SAN disks to this host.
1. Start the VMware vSphere client and connect to the host using the host IP address.
Doing this connects your client to the host. You are now ready to configure the host.
1. After you have connected to your remote device through the hypervisor, choose the Configuration
tab of the host and choose Storage for Hardware.
For example, the following example shows that the host has two local hard drives available, datastore1
and datastore2.
4. In the iSCSI Initiator (iSCSI Software Adapter) Properties dialog box, choose Configure.
5. In the General Properties dialog box, select the Enabled check box to set the software initiator
status to enabled, and then choose OK.
6. In the iSCSI Initiator (iSCSI Software Adapter) Properties dialog box, choose the Dynamic
Discovery tab, and then choose Add to add an iSCSI target.
7. In the Add Send Target Server dialog box, type a name for iSCSI Server and a port for Port, and
then choose OK.
The new iSCSI server location that you type here appears in the Sends Target list on the Dynamic
Discovery tab.
8. Choose Close to close the iSCSI Initiator (iSCSI Software Adapter) Properties dialog box.
Now you have added a new iSCSI target in the host configuration.
The following table describes the subset of Hyper-V components that you typically work with when using
AWS Storage Gateway.
Component Description
Component Description
Hyper-V Manager The Hyper-V client software that you use on your
computer to access and manage your Hyper-V
environment. You manage your virtual machine
(that contains the gateway) using the client.
Import files (packaging of VM) The AWS Storage Gateway appliance is distributed
as a compressed directory containing the following:
• How to troubleshoot certain basic setup issues: Troubleshooting Your Microsoft Hyper-V Setup (p. 376)
Refer to the Hyper-V Getting Started Guide on the Microsoft TechNet site for more information about the
installation of Hyper-V.
Depending on your computer's BIOS settings, the computer might automatically boot off your disk.
If not, check the relevant settings to boot the computer from the hypervisor disk.
3. Follow the instructions on the monitor to install the Hyper-V hypervisor OS.
This installation wipes any existing content on the disk and installs the hypervisor.
After a successful Hyper-V hypervisor host installation, you will be prompted to create an Administrator
account password. After creating this account, the monitor displays a Server Configuration menu
where you will do further configuration of the host.
4. In the Server Configuration menu, configure the host. We recommend the following:
To Do This
Find the network ad- Choose option 8 and follow the prompts. Note the IP address for use later.
dress of the host.
Set the date and Choose option 9 and follow the prompts.
time.
(Optional) Change Choose option 2 and follow the prompts. Because this change requires a
the computer name. reboot, you might want to make this configuration change last.
To Do This
5. (Optional) You might need to put the IP address of the hypervisor host in your hosts file of client
computers that connect to the hypervisor host.
For example, in Windows 7 and 8, the hosts file can be found at this location:
%SystemRoot%\system32\drivers\etc\hosts
Note
The Hyper-V Manager is a feature that you enable for your client computer. For more
information about enabling it, go to Install and Configure Hyper-V Tools for Remote
Administration on the Microsoft Windows Server website.
Note
To connect to a hypervisor host using the host name, you might need to make an entry in
your hosts file so that the host name can be mapped to the correct IP address.
Note
If you have not been added to the local administrators for the hypervisor host, you might be
prompted for credentials.
The following example shows Hyper-V Manager connected to a hypervisor host called
HYPERV-SERVER with one gateway VM.
4. In the Virtual Network Manager dialog box, choose New virtual network.
5. Choose External as the virtual network type, and then choose Add.
When you configure your gateway virtual machine, you can use this virtual network.
7. Choose OK.
You try to import a gateway This error can occur for the following reasons:
and receive the error mes-
sage: "Import failed. Unable • If you are not pointing to the root of the unzipped gateway source
to find virtual machine import files. The last part of the location you specify in the Import Virtual
file under location ...". Machine dialog box should be AWS-Storage-Gateway, as the fol-
lowing example shows:
• If you have already deployed a gateway and you did not select the
Copy the virtual machine option and check the Duplicate all files
option in the Import Virtual Machine dialog box, then the VM was
created in the location where you have the unzipped gateway files
and you can not import from this location again. To fix this problem,
get a fresh copy of the unzipped gateway source files and copy to a
new location. Use the new location as the source of the import. The
following example shows the options that you must check if you plan
on creating multiple gateways from one unzipped source files location.
For more information about deploying a gateway, see Step 2.2: Download
and Deploy the AWS Storage Gateway VM on Your Host (p. 39).
You try to import a gateway If you have already deployed a gateway and you try to reuse the default
and receive the error mes- folders that store the virtual hard disk files and virtual machine configur-
sage: "Import failed. Import ation files, then this error will occur. To fix this problem, specify new
task failed to copy file." locations in the Hyper-V Settings dialog box.
You try to import a gateway When you import the gateway make sure you select the Copy the vir-
and receive an error mes- tual machine option and check the Duplicate all files option in the
sage: "Import failed. Import Import Virtual Machine dialog box to create a new unique ID for the
failed because the virtual ma- VM. The following example shows the options in the Import Virtual
chine must have a new identi- Machine dialog box that you should use.
fier. Select a new identifier
and try the import again."
You try to start a gateway VM This error is likely caused by a CPU discrepancy between the required
and receive an error message CPUs for the gateway and the available CPUs on the host. Ensure that
"The child partition processor the VM CPU count is supported by the underlying hypervisor.
setting is incompatible with For more information about the requirements for AWS Storage Gateway,
parent partition." see Requirements (p. 12).
You try to start a gateway VM This error is likely caused by a RAM discrepancy between the required
and receive an error message RAM for the gateway and the available RAM on the host.
"Failed to create partition: In-
sufficient resources exist to For more information about the requirements for AWS Storage Gateway,
complete the requested ser- see Requirements (p. 12).
vice."
Your snapshots and gateway The gateway VM's clock might be offset from the actual time, known as
software updates are occur- clock drift. Check and correct the VM's time using local gateway console's
ring at slightly different times time synchronization option. For more information, see Synchronizing
than expected. Your Gateway VM Time (p. 272).
You need to put the unzipped Access the host as you do a typical Microsoft Windows server. For ex-
Microsoft Hyper-V AWS Stor- ample, if the hypervisor host is name hyperv-server, then you can
age gateway files on the host use the following UNC path \\hyperv-server\c$, which assumes
file system. that the name hyperv-server can be resolved or is defined in your
local hosts file.
You are prompted for creden- Add your user credentials as a local administrator for the hypervisor
tials when connecting to hy- host by using the Sconfig.cmd tool. For more information, see Setting
pervisor. Up and Configuring a Microsoft Hyper-V Host (p. 371).
Important
Do not remove a disk allocated for cache storage.
For information about how to add a disk to a gateway hosted on VMware ESXi, see Step 2.3: Provision
Local Disk Storage for the Gateway VM (VMWare) (p. 26).
For information about how to add a disk to a gateway hosted on Microsoft Hyper-V, see Step 2.3: Provision
Local Storage for the AWS Storage Gateway VM (Hyper-V) (p. 48).
Topics
• Remove a Disk from a Gateway Hosted on VMware ESXi (p. 380)
• Remove a Disk from Gateway Hosted on Microsoft Hyper-V (p. 381)
1. In the vSphere client, open the context (right-click) menu, choose the name of your gateway VM,
and then choose Edit Settings.
2. On the Hardware tab of the Virtual Machine Properties dialog box, select the disk allocated as
upload buffer space, and then choose Remove.
Verify that the Virtual Device Node value in the Virtual Machine Properties dialog box has the
same value that you noted previously. Doing this helps ensure that you remove the correct disk.
3. Choose an option in the Removal Options panel, and then choose OK to complete the process of
removing the disk.
To remove an underlying disk allocated for the upload buffer (Microsoft Hyper-V)
1. In the Microsoft Hyper-V Manager, open the context (right-click) menu, choose the name of your
gateway VM, and then choose Settings.
2. In the Hardware list of the Settings dialog box, select the disk to remove, and then choose Remove.
The disks you add to a gateway appear under the SCSI Controller entry in the Hardware list. Verify
that the Controller and Location value are the same value that you noted previously. Doing this
helps ensure that you remove the correct disk.
The first SCSI controller displayed in the Microsoft Hyper-V Manager is controller 0.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://
www.openssl.org/).
The packages that make up the AWS Storage Gateway VM are tracked and monitored for security
vulnerabilities. When updates are issued, they are applied to each gateway and the updated packages
will increment their version number, although the major version number of the Linux distribution might
not increment.
AWS Storage Gateway–VTL supports backing up data to virtual tapes and archiving the tapes in the
virtual tape shelf (VTS) by using Symantec Backup Exec 2012. Following, you can find basic documentation
on performing this type of backups, including how to configure storage, write data to a virtual tape, archive
the tape in the VTS, and restore the data. For detailed information about how to use Backup Exec 2012,
go to the Backup Exec documentation on the Symantec website.
Topics
• Configuring Storage in Backup Exec 2012 (p. 383)
• Importing a Tape in Backup Exec 2012 (p. 384)
• Writing Data to a Tape in Backup Exec 2012 (p. 385)
• Archiving a Tape Using Backup Exec 2012 (p. 385)
• Restoring Data from a Tape Archived in Backup Exec 2012 (p. 386)
• Disabling a Tape Drive in Backup Exec 2012 (p. 386)
To configure storage
1. Start the Backup Exec 2012 software, and then choose the yellow icon in the top left corner on the
toolbar.
2. Choose Configuration and Settings, and then choose Backup Exec Services to open the Backup
Exec Service Manager.
3. Choose Restart All Services. Backup Exec 2012 then recognizes the VTL devices (that is, the
medium changer and tape drives). The restart process might take a few minutes.
Note
AWS Storage Gateway–VTL provides 10 tape drives. However, your Backup Exec 2012
license agreement might require your backup software to work with fewer than 10 tape
drives. In that case, you must disable tape drives in the Backup Exec 2012 robotic library
to leave only the number of tape drives allowed by your license agreement enabled. For
instructions, see Disabling a Tape Drive in Backup Exec 2012 (p. 386).
4. After the restart is completed, close the Backup Exec Service Manager.
1. Choose the Storage tab, and then expand the Robotic library tree to display the VTL devices.
4. In the Media Request window that appears, choose the Details link.
5. In the Action Alert: Media Intervention window, choose Respond OK to insert the media into the
slot.
1. Choose the Storage menu, choose Slots, open the context (right-click) menu for the slot you want
to export the tape from, choose Export media now, and then choose Export media now again.
You can select more than one slot and export multiple tapes in a single export operation.
2. In the Media Request pop-up window, choose Details, and then choose Respond OK in the Alert:
Media Intervention window.
In the AWS Storage Gateway console, you can verify the status of the tape you are archiving. It might
take some time to finish uploading data to AWS. During this time, the exported tape will be listed in
the gateway's VTL with the status IN TRANSIT TO VTS. When the upload is completed and the
archiving process begins, the status changes to ARCHIVING. When data archiving has completed,
the exported tape will no longer be listed in the VTL.
3. Choose your gateway, and then choose VTL Tape Cartridges and verify that the virtual tape is no
longer listed in your gateway.
4. On the Navigation pane of the AWS Storage Gateway console, choose Virtual Tape Shelf (VTS).
Verify that your archived tape is listed in the VTS and that the status is ARCHIVED.
1. Retrieve the archived tape from your VTS to a gateway-VTL. For instructions, see Retrieving the
Archived Tape from the VTS Back to Your Gateway-VTL (p. 124).
2. Use Backup Exec 2012 to restore the data. This process is the same as restoring data from physical
tapes. For instructions, go to the Backup Exec documentation on the Symantec website.
The following table describes important changes to the documentation since the last release of the AWS
Storage Gateway User Guide.
Compatibility with AWS Storage Gateway–VTL is now compatible with In this release
Veeam Backup & Veeam Backup & Replication V9 Update 2 or later (that
Replication V9 Up- is, version 9.0.0.1715 or later). You can now use Veeam
date 2 or later Backup Replication V9 Update 2 or later to back up your
data to Amazon S3 and archive directly to Amazon Glacier.
For more information, see Testing Your Setup by Using
Veeam Backup & Replication (p. 134).
Longer volume and AWS Storage Gateway is introducing longer IDs for April 25, 2016
snapshot IDs volumes and snapshots. You can enable the longer ID
format for your volumes, snapshots, and other supported
AWS resources. For more information, see Understanding
AWS Storage Gateway Resources and Resource
IDs (p. 215).
New region AWS Storage Gateway–VTL is now available in the Asia March 21, 2016
Pacific (Seoul) region. For more information, see Available
Support for storage AWS Regions (p. 7).
up to 512 TiB in size
for gateway-stored For gateway-stored volumes, you can now create up to
volumes 32 storage volumes up to 16 TiB in size each, for a max-
imum of 512 TiB of storage. For more information, see
Other gateway up- Gateway-Stored Volume Architecture (p. 4) and AWS
dates and enhance- Storage Gateway Limits (p. 362).
ments to the AWS
Storage Gateway Total size of all tapes in a virtual tape library is increased
local console to 1 PiB. For more information, see AWS Storage Gateway
Limits (p. 362).
You can now set the password for your VM local console
on the AWS Storage Gateway Console. For information,
see Setting the Local Console Password from the Storage
Gateway Console (p. 266).
Compatibility with AWS Storage Gateway–VTL is now compatible with EMC February 29, 2016
for EMC NetWorker NetWorker 8.x. You can now use EMC NetWorker to back
8.x up your data to Amazon S3 and archive directly to Amazon
Glacier. For more information, see Testing Your Setup by
Using EMC NetWorker (p. 140).
Support for VMware AWS Storage Gateway now supports the VMware ESXi October 20, 2015
ESXi Hypervisor Hypervisor version 6.0 and the Red Hat Enterprise Linux
version 6.0 and Red 7 iSCSI initiator. For more information, see Supported
Hat Enterprise Linux Hypervisors and Host Requirements (p. 12) and Supported
7 iSCSI initiator iSCSI Initiators (p. 13).
Support for storage For gateway-cached volumes, you can now create up to September 16, 2015
up to 1,024 TiB in 32 storage volumes at up to 32 TiB each for a maximum
size for gateway- of 1,024 TiB of storage. For more information, see Gate-
cached volumes way-Cached Volume Architecture (p. 3) and AWS Storage
Gateway Limits (p. 362).
Support for the
VMXNET3 (10 GbE) If your gateway is hosted on a VMware ESXi hypervisor,
network adapter you can reconfigure the gateway to use the VMXNET3
type in VMware ES- adapter type. For more information, see Configuring Net-
Xi hypervisor work Adapters for Your Gateway (p. 276).
Performance en- The maximum upload rate for AWS Storage Gateway has
hancements increased to 120 MB a second, and the maximum down-
load rate has increased to 20 MB a second. For more in-
Miscellaneous en- formation, see Configuration and Performance Lim-
hancements and its (p. 363).
updates to the AWS
Storage Gateway The AWS Storage Gateway local console has been up-
local console dated and enhanced with additional features to help you
perform maintenance tasks. For more information, see
Configuring Your Gateway Network (p. 268).
Support for tagging AWS Storage Gateway now supports resource tagging. September 02, 2015
You can now add tags to gateways, volumes, and virtual
tapes to make them easier to manage. For more informa-
tion, see Tagging Storage Gateway Resources (p. 248).
Compatibility with AWS Storage Gateway–VTL is now compatible with Dell June 22, 2015
Dell NetVault NetVault Backup 10.0. You can now use Dell NetVault
Backup 10.0 Backup 10.0 to back up your data to Amazon S3 and
archive directly to Amazon Glacier. For more information,
see Testing Your Setup by Using Dell NetVault
Backup (p. 137).
Support for 16 TiB AWS Storage Gateway now supports 16 TiB storage June 03, 2015
storage volumes for volumes for Gateway-stored setups. You can now create
Gateway-stored 12 16 TiB storage volumes for a maximum of 192 TiB of
setups storage. For more information, see Gateway-Stored
Volume Architecture (p. 4).
Support for system
resource checks on You can now determine whether your system resources
the AWS Storage (virtual CPU cores, root volume size, and RAM) are suffi-
Gateway local con- cient for your gateway to function properly. For more in-
sole formation, see Viewing Your Gateway System Resource
Status (p. 275) or Viewing Your Gateway System Resource
Support for the Red Status (p. 275).
Hat Enterprise Linux
6 iSCSI initiator AWS Storage Gateway now supports the Red Hat Enter-
prise Linux 6 iSCSI initiator. For more information, see
Requirements (p. 12).
Support for Mi- AWS Storage Gateway now supports Microsoft Hyper-V April 30, 2015
crosoft Hyper-V hy- hypervisor versions 2012 and 2012 R2. This is in addition
pervisor versions to support for Microsoft Hyper-V hypervisor version 2008
2012 and 2012 R2 R2. For more information, see Supported Hypervisors and
Host Requirements (p. 12).
Compatibility with AWS Storage Gateway–VTL is now compatible with Sy- April 06, 2015
Symantec Backup mantec Backup Exec 15. You can now use Symantec
Exec 15 Backup Exec 15 to back up your data to Amazon S3 and
archive directly to Amazon Glacier. For more information,
see Testing Your Setup by Using Symantec Backup Ex-
ec (p. 127).
CHAP authentica- AWS Storage Gateway now supports configuring CHAP April 02, 2015
tion support for stor- authentication for storage volumes. For more information,
age volumes see Step 3: Create Volumes (p. 79).
Support for VMware AWS Storage Gateway now supports VMware ESXi Hy- March 30, 2015
ESXi Hypervisor pervisor versions 5.1 and 5.5. This is in addition to support
version 5.1 and 5.5 for VMware ESXi Hypervisor versions 4.1 and 5.0. For
more information, see Supported Hypervisors and Host
Requirements (p. 12).
Support for Win- AWS Storage Gateway now supports the Windows CHK- March 04, 2015
dows CHKDSK util- DSK utility. You can use this utility to verify the integrity of
ity your volumes and fix errors on the volumes. For more in-
formation, see Troubleshooting Volume Issues (p. 304).
Integration with AWS Storage Gateway is now integrated with AWS December 16, 2014
AWS CloudTrail to CloudTrail. AWS CloudTrail captures API calls made by
capture API calls or on behalf of AWS Storage Gateway in your AWS ac-
count and delivers the log files to an Amazon S3 bucket
that you specify. For more information, see Logging AWS
Storage Gateway API Calls by Using AWS
CloudTrail (p. 235).
Compatibility with AWS Storage Gateway–VTL is now compatible with the November 3, 2014
additional backup following backup software:
software and medi-
um changer • Symantec Backup Exec 2014
• Microsoft System Center 2012 R2 Data Protection
Manager
• Veeam Backup & Replication V7
• Veeam Backup & Replication V8
EU (Frankfurt) re- AWS Storage Gateway is now available in the EU October 23, 2014
gion (Frankfurt) region. For detailed information, see Available
AWS Regions (p. 7).
Content restructure Created a Getting Started section that is common to all May 19, 2014
gateway solutions. This section provides instructions for
you to download, deploy, and activate a gateway. After
you deploy and activate a gateway, you can proceed to
further instructions specific to gateway-stored, gateway-
cached, and gateway-VTL setups. For more information,
see Getting Started with AWS Storage Gateway (p. 10).
Compatibility with AWS Storage Gateway–VTL is now compatible with Sy- April 28, 2014
Symantec Backup mantec Backup Exec 2012. You can now use Symantec
Exec 2012 Backup Exec 2012 to back up your data to Amazon S3
and archive directly to Amazon Glacier. For more informa-
tion, see Using Symantec Backup Exec 2012 to Test Your
Setup (p. 383).
Support for Win- • Gateway-cached and gateway-stored volumes can now January 31, 2014
dows Server Fail- be used as storage for applications configured using
over Clustering Windows Server Failover Clustering (WSFC). This en-
ables coordinated iSCSI access to AWS Storage Gate-
Support for VMware way volumes by applications clustered using WSFC.
ESX initiator
• AWS Storage Gateway now enables you to manage
Support for perform- storage connectivity directly through your ESX host.This
ing configuration provides an alternative to using initiators resident in the
tasks on AWS Stor-
guest OS of your VMs.
age Gateway local
console
• AWS Storage Gateway now provides support for per-
forming configuration tasks in the AWS Storage Gateway
local console. For information about performing config-
uration tasks on gateways deployed on-premises, see
Performing Maintenance Tasks on the VM Local Con-
sole (p. 262) or Performing Maintenance Tasks on the
VM Local Console (p. 262). For information about per-
forming configuration tasks on gateways deployed on
an EC2 instance, see Performing Maintenance Tasks
on the Amazon EC2 Gateway Local Console (p. 286) or
Performing Maintenance Tasks on the Amazon EC2
Gateway Local Console (p. 286).
Support for virtual AWS Storage Gateway connects an on-premises software November 5, 2013
tape library (VTL) appliance with cloud-based storage to integrate your on-
and introduction of premises IT environment with the AWS storage infrastruc-
API version 2013- ture. In addition to volume gateways (gateway-cached and
06-30 gateway-stored), AWS Storage Gateway now supports
gateway–virtual tape library (VTL). You can configure
gateway-VTL with up to 10 virtual tape drives per gateway.
Each virtual tape drive responds to the SCSI command
set, so your existing on-premises backup applications will
work without modification. For more information, see the
following topics in the AWS Storage Gateway User Guide.
Support for Mi- AWS Storage Gateway now provides the ability to deploy April 10, 2013
crosoft Hyper-V an on-premises gateway on the Microsoft Hyper-V virtual-
ization platform. Gateways deployed on Microsoft Hyper-
V have all the same functionality and features as the exist-
ing on-premises storage gateway.To get started deploying
a gateway with Microsoft Hyper-V, see Hyper-V
Host (p. 38).
Support for deploy- AWS Storage Gateway now provides the ability to deploy January 15, 2013
ing a gateway on a gateway in Amazon Elastic Compute Cloud (Amazon
Amazon EC2 EC2).You can launch a gateway instance in Amazon EC2
using the AWS Storage Gateway AMI available in AWS
Marketplace. To get started deploying a gateway using
the AWS Storage Gateway AMI, go to Amazon EC2
Gateway (p. 60).
Support for gate- In this release, AWS Storage Gateway introduces support October 29, 2012
way-cached for gateway-cached volumes. Gateway-cached volumes
volumes and intro- minimize the need to scale your on-premises storage infra-
duction of API Ver- structure, while still providing your applications with low-
sion 2012-06-30 latency access to their active data.You can create storage
volumes up to 32 TiB in size and mount them as iSCSI
devices from your on-premises application servers. Data
written to your gateway-cached volumes is stored in
Amazon Simple Storage Service (Amazon S3), with only
a cache of recently written and recently read data stored
locally on your on-premises storage hardware. Gateway-
cached volumes allow you to utilize Amazon S3 for data
where higher retrieval latencies are acceptable, such as
for older, infrequently accessed data, while maintaining
storage on-premises for data where low-latency access is
required.
API and IAM Sup- In this release, AWS Storage Gateway introduces API May 9, 2012
port support as well as support for AWS Identity and Access
Management(IAM).
Static IP Support You can now specify a static IP for your local gateway. March 5, 2012
For more information, see Configuring Your Gateway
Network (p. 268).
New Guide This is the first release of AWS Storage Gateway User January 24, 2012
Guide.