text: <html>
          <head> <meta charset="UTF-8">
          <style>
          table, th, td {
              border: 1px solid black;
              font-size: 10px;
          }
          </style> </head>
          <body>
          <table frame="hsides" rules="groups" width="100%%">
              [html]<thead><tr><td>FNAB1. TUG ≥ 010 / μl osinks / p < underline > GU13 / de </ underline > U / drink / all / ull / dr / to / all / drink / drink / rh, GdU / dl</td><td>when choosing to use Transparent Cloud Tiering.</td></tr></thead><tbody><tr></tr></tbody>
          </table> </body> </html>
  
  The restore of individual files using Transparent Cloud Tiering is not possible. As mentioned, 
  object storage is unlike a file or a block so object storage must be managed as a whole unit 
  piece of storage, and not partially. Cloud object storage is accessible by using an 
  HTTP-based REST API. 
  
  **11.3.4 Transparent Cloud Tiering restrictions**
  
  This section describes the following restrictions that must be considered before using 
  Transparent Cloud Tiering: 
  
  (cid:2) Because the object storage is normally accessed by using the HTTP protocol on top of a 
  TPC/IP stack, all traffic that is associated with cloud service flows through the node 
  management ports. 
  
  (cid:2) The size of cloud-enabled volumes cannot change. If the size of the volume changes, a 
  snapshot must be created so that a new Object Storage is constructed. 
  
  (cid:2) Transparent Cloud Tiering cannot be applied to volumes that are part of traditional copy 
  services, such as FlashCopy, Metro Mirror, Global Mirror, and HyperSwap. 
  
  (cid:2) Volume containing two physical copies in two different storage pools cannot be part of 
  Transparent Cloud Tiering. 
  
  (cid:2) Cloud Tiering snapshots cannot be taken from a volume that is part of migration activity 
  across storage pools. 