AWS Storage Gateway User Guide
Tape Gateways
• Virtual tape library (VTL) – A VTL is like a physical tape library available on-premises with robotic
arms and tape drives. Your VTL includes the collection of stored virtual tapes. Each tape gateway
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 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.
• Archive – Archive is analogous to an offsite tape holding facility. You can archive tapes from your
gateway's VTL to the archive. If needed, you can retrieve tapes from the archive back to your gateway's
VTL.
• Archiving tapes – When your backup software ejects a tape, your gateway moves the tape to the
archive for long-term storage. The archive is located in the AWS Region in which you activated the
gateway. Tapes in the archive are stored in the virtual tape shelf (VTS). The VTS is backed by S3
Glacier or S3 Glacier Deep Archive, low-cost storage service for data archiving, backup, and long-
term data retention.
• Retrieving tapes – You can't read archived tapes directly. To read an archived tape, you must first
retrieve it to your tape gateway either by using the Storage Gateway console or by using the Storage
Gateway API. When you retrieve a tape that is archived in GLACIER, it becomes available in your VTL
in about three to five hours after you start retrieval. When you retrieve a tape that is archived in
DEEP_ARCHIVE, it becomes available in your VTL in about 12 hours after you start retrieval.
After you deploy and activate a tape gateway, you mount the virtual tape drives and media changer on
your on-premises application servers as iSCSI devices. You create virtual tapes as needed. Then you 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.
Allocating Local Disks for the Gateway VM
Your gateway VM needs local disks, which you allocate for the following purposes:
• 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 Tape Gateway (p. 335).
As your backup application writes data to your gateway, the gateway copies data to both the cache
storage and the upload buffer. It then acknowledges completion of the write operation to your backup
application.
For guidelines on the amount of disk space to allocate for the cache storage and upload buffer, see
Deciding the Amount of Local Disk Storage (p. 220).
API Version 2013-06-30
7
To Next Page
Loading...