Data Domain Restorer (DDR) and Long Term Retention (LTR) to the Cloud Frequently Asked Questions (FAQ / FAQs)

           

   Article Number:     506168                                   Article Version: 13     Article Type:    How To 
   

 


Product:

 

Data Domain,DD OS

 

Instructions:

 

 

This article attempts to address some of the more frequently asked questions regarding configuration/use of Data Domain Restorers (DDRs) and LTR (Long Term Retention) or Cloud feature.   
   
    Overview/what is LTR?   

         
  •         Starting with DDOS (Data Domain Operating System) 6.0, a new feature called LTR was introduced.     
  •      
  •         LTR allows certain models of DDRs to migrate a subset of files/data to object/cloud storage, known as a cloud tier, from a range of supported public/private cloud providers.     
  •      
  •         To physically migrate files/data to object storage a data movement process is run on the DDR.     
  •      
  •         To physically free redundant data from the cloud tier, a cloud tier cleaning process is run on the DDR.     
  •      
  •         LTR is a licensed feature and requires a "CLOUDTIER_CAPACITY" license.     
  •      
  •         LTR requires some local storage for cloud tier metadata.     
  •    
What DDR system(s) is LTR available for?   
   
    Depending upon the DDOS version installed, the following DDR models are supported:   
         
  •         DD4200     
  •      
  •         DD4500     
  •      
  •         DD7200     
  •      
  •         DD990     
  •      
  •         DD9500     
  •      
  •         DD9800     
  •      
  •         DD6800     
  •      
  •         DD9300     
  •      
  •         DDVE     
  •    
    Most models have certain hardware requirements that must be fulfilled in advance for LTR to be configured, please refer to the hardware/installation guide for the specific model.   
   
    What license is required for LTR?   
         
  •         As LTR is considered a new feature from DDOS 6.x onwards, an elicense is required.      
  •      
  •         The type of elicense required is called a 'CLOUDTIER_CAPACITY' license. An example of a CLOUDTIER_CAPACITY license is as follows:     
  •    
   
      Capacity licenses:       
        ##   Feature              Shelf Model   Capacity     Mode        Expiration Date       
        --   ------------------   -----------   ----------   ---------   ---------------       
        1    CLOUDTIER-CAPACITY   n/a           136.42 TiB   permanent   n/a       
        --   ------------------   -----------   ----------   ---------   ---------------
   
   
    How do the different tiers work?   
         
  •         Normal DDRs (without an LTR license) have a single tier known as the active tier.     
  •      
  •         The active tier is the traditional tier of storage on all 'standard' DDRs.     
  •      
  •         LTR systems have a second tier of storage known as a cloud tier.     
  •    
    Note that the maximum size of each tier will be dictated by the supported limits for the given hardware configuration/DDOS version. Please refer to the DDOS administration guide and the hardware guide for the specific model in question.   
   
    An example of a two tier, one active and one cloud, LTR configuration is shown below:   
     
      Active Tier:       
        Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB*       
        ----------------   --------   --------   ---------   ----   --------------       
        /data: pre-comp           -    36674.6           -      -                -       
        /data: post-comp    65460.3      585.4     64874.8     1%              0.1       
        /ddvar                 29.5       24.7         3.3    88%                -       
        /ddvar/core            31.5        1.1        28.8     4%                -       
        ----------------   --------   --------   ---------   ----   --------------       
       
        Cloud Tier       
        Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB       
        ----------------   --------   --------   ---------   ----   -------------       
        /data: pre-comp           -       33.1           -      -               -       
        /data: post-comp      912.2       42.3       869.9     5%             4.1       
        ----------------   --------   --------   ---------   ----   -------------       
       
        Total:       
        Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB       
        ----------------   --------   --------   ---------   ----   -------------       
        /data: pre-comp           -    36674.6           -      -               -       
        /data: post-comp    65460.3      585.4     64874.8     1%             0.1       
        /ddvar                 29.5       24.7         3.3    88%               -       
        /ddvar/core            31.5        1.1        28.8     4%               -       
        ----------------   --------   --------   ---------   ----   -------------
   
   
    How is a cloud tier structured?   
         
  •         A cloud tier comprises:     
  •    
   
         
  1.         Locally held metadata, stored on an enclosure if a physical DDR is used, or a lun/device if DDVE is used.     
  2.      
  3.         Object storage provider(s).     
  4.    
   
         
  •         Both of the above are combined into a cloud unit.     
  •      
  •         If multiple cloud units are configured, they can share the locally held metadata.     
  •      
  •         A maximum of two cloud units can be configured per system. Each cloud unit can be provisioned from a different object storage provider.     
  •      
  •         Each cloud unit can be as large as the maximum supported active tier size for the given model of DDR. Please refer to the DDOS administration guide for further information.     
  •    
What happens during a typical backup lifecycle when LTR is configured?   
         
  •         All data is initially written to the active tier where it starts to age.     
  •      
  •         Short lived data that reaches it's retention period is expired/deleted as on a normal DDR.     
  •      
  •         A subset of data requiring long term retention, however, is migrated out to the cloud tier.     
  •      
  •         The filesystem maintains a single namespace across all tiers so when a file migrates to the cloud, the namespace does not change and as such, is reasonably transparent to the user/backup application.     
  •      
  •         For a file that has already been migrated to the cloud tier reaches it's retention period, it is expired/deleted as any other file would.     
  •      
  •         The space that a file was using in the cloud tier is not reclaimed immediately, instead cloud tier cleaning must be run.     
  •    
How is data de-duplicated between tiers?   
         
  •         Each cloud unit is a stand alone volume meaning that it is a self contained de-duplication unit.     
  •      
  •         As a result data written to each cloud unit can only de-duplicate against data in the same cloud unit.     
  •    
What is a placement time (sometimes referred to as ptime)?   
         
  •         ​Files and/or directories have various timestamps associated with them.     
  •      
  •         For example, a file/directory will have a creation time, last access time and modification time.     
  •      
  •         DDOS has enhanced this further to also include a placement time. The placement time is the date/time that the file migrated from the active tier to the cloud tier.     
  •      
  •         Depending upon the DDOS version, the placement time can be seen when examining which tier a file resides on. If the file has migrated to the cloud tier, the placement time will be shown, for example:     
  •    
   
      sysadmin@dd4500 # filesys report generate file-location       
        --------------------------------      ---------------------------       
        File Name                             Location(Unit Name)       
        --------------------------------      ---------------------------       
        /data/col1/mtree1/random-data-file-4        cloudunit2           Tue Sep 5 10:17:00 2017       
        /data/col1/mtree1/random-data-file-5        cloudunit2           Tue Sep 12 15:52:23 2017       
        /data/col1/mtree1/random-data-file-6        cloudunit2           Tue Sep 13 09:42:55 2017
   
   
         
  •         Note, ptime is the last field in the above output, although it does not display a field header.     
  •    
How does data move from the active tier to the cloud tier?   
         
  •         ​A process called data movement is responsible for examining files within an mtree that reside in the active tier.     
  •      
  •         Data movement starts by creating a snapshot of all mtrees configured for data movement.     
  •      
  •         Each file has a modification time which stores the last time a file was written to.     
  •      
  •         If a file previously migrated to the cloud tier, an additional time field called a placement time is set. The placement time stores the date/time that the file migrated to the cloud tier.  If the placement time is set, this will be used instead of the modification time. This is to avoid a file being continually migrating back to the cloud tier if a file is recalled (as recalling a file won't change it's modification time).     
  •      
  •         The snapshots created above are traversed by data movement.     
  •      
  •         If the file being examined has reached a defined threshold value, as set by the data movement policy for the mtree in question, the file is examined to ascertain what data held in that file needs to migrate from the active tier to cloud tier. A data movement policy is set per mtree.     
  •      
  •         The unique segments for the selected file are written/copied to the cloud tier.      
  •      
  •         Once the unique segments have been copied, the file is verified by reading them back to ensure that migration was successful.     
  •      
  •         Once the file has been verified, the meta data is updated to reflect that the file now resides upon the cloud tier.     
  •      
  •         The data movement process can be scheduled to run at a certain frequency or can be manually initiated.     
  •    
When data movement is started, what phases are there and what actions does each phase perform?   
         
  •         There are 3 phases associated with data movement, the copy phase, the verify phase and the install phase.     
  •      
  •         The copy phase is responsible for identifying segments that need to be copied to the cloud and then migrating these segments to the cloud.     
  •      
  •         Once the copy phase starts, it is at this point cloud/object storage will be used as the copy phase copies the segments identified from the active tier to the cloud tier.     
  •      
  •         The verify phase is responsible for ensuring that a files' segments were successfully migrated to the cloud.     
  •      
  •         The install phase is responsible for updating the metadata, pertaining to file that was migrated, to show that it now resides on cloud/object storage.     
  •      
  •         Each file will have to complete all 3 phases in order for data movement to be deemed successful for that file. Therefore, until the install phase completes for a file, the file will remain in the active tier.     
  •    
What data movement policies are available?   
         
  •         Data movement policies can be one of the following:     
  •    
   
         
  1.         Age threshold : If a files placement/modification time is greater than the age range set, it will be selected for migration to the cloud tier.     
  2.      
  3.         Age range : If a files placement/modification time falls within a certain range, it will be selected for migration to the cloud tier.     
  4.      
  5.         Application defined. The backup application designates if a file is to be selected for migration to the cloud tier.     
  6.    
   
         
  •         Note that policies are mutually exclusive, i.e. an mtree can only have 1 policy set at a time.     
  •    
How can a data movement policy be set on an mtree?   
         
  •         The command 'data-movement policy set <policy name> <policy type values> totier cloud cloud-unit <cloud unit name> mtrees <mtree list>' can be used. For example:     
  •    
   

      sysadmin@dd4500 # data-movement policy set age-threshold 14 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1       
        sysadmin@dd4500 # data-movement policy set age-range min-age 14 max-age 100 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1       
        sysadmin@dd4500 # data-movement policy set app-managed to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
   

   
       
What data movement policies are already configured?   
         
  •         The command 'data-movement policy show' will provide a list of which mtrees have any data movement policies assigned to them. For example:     
  •    
   
      sysadmin@dd4500 # data-movement policy show       
        Mtree               Target(Tier/Unit Name)   Policy      Value             
        -----------------   ----------------------   ---------   -----------       
        /data/col1/mtree1   Cloud/cloudunit1         age-range   14-100 days       
        -----------------   ----------------------   ---------   -----------
   
   
    How does an app-managed data-movement policy work?   
         
  •         The data-movement policy for the mtree in question is set to app-managed. This is either done manually, or the backup application performs this via the Data Domain REST API interface.     
  •      
  •         The backup application must be LTR aware.     
  •      
  •         The backup application must use DDBoost and the version of DDBoost must be LTR aware/compatible.     
  •      
  •         Via the DDBoost library/API, the backup application will set the placement time for the file that needs to migrated to the cloud tier is set to a special value indicating that next time data movement runs, the file is to be migrated to the cloud.     
  •      
  •         When data movement runs on the Data Domain system, the placement time is checked and if it's set to the special value, as mentioned above, then it will migrate the file to the cloud.     
  •    
How can data movement be started manually?   
         
  •         The command "data-movement start" can be used, for example:     
  •    
   
      sysadmin@dd4500 # data-movement start       
        Data-movement started.
   
   
    How can data movement be monitored?   
         
  •         To check the status of data movement, the command 'data-movement status' can be used. For example:     
  •    
   
      sysadmin@dd4500 # data-movement status       
        Data-movement to cloud tier:       
        ----------------------------       
        Data-movement is initializing..       
       
        Data-movement recall:       
        ---------------------       
        No recall operations found.
    
   
         
  •         If data movement is running, the command 'data-movement watch' can be used, for example:     
  •    
   
      sysadmin@dd4500 # data-movement watch       
        Data-movement: phase 1 of 3 (copying)       
           92% complete; time: phase  0:08:04, total  0:08:14       
              Copied (post-comp): 3.35 GiB, (pre-comp): 3.29 GiB,B,       
              Files copied: 7, Files verified: 3, Files installed: 3
   
   
    How can data movement be stopped?   
         
  •         The command 'data-movement stop' can be used. For example:     
  •    
   
      sysadmin@dd4500 # data-movement stop       
        Data-movement stop initiated. Run the status command to check its status.
   
   
    If there is more than one cloud unit, can data movement run to both cloud units in parallel?   
         
  •         No. Essentially data movement can only migrate data to one cloud unit at a time.     
  •    
How is LTR configured?   
         
  •         This is just a high level overview, please refer to the detailed process in the DDOS administration guide.     
  •      
  •         Add the appropriate CLOUDTIER_CAPACITY license.     
  •      
  •         Set the system passphrase if it is not already set.     
  •      
  •         Enable the cloud feature.     
  •      
  •         Add the metadata storage for the cloud tier.     
  •      
  •         Configure a cloud profile or profiles for the appropriate cloud/object storage vendor.     
  •      
  •         Add a cloud unit.     
  •      
  •         Configure a data movement policy for the mtree or mtrees that require storing data in the cloud.     
  •      
  •         Start data movement manually or wait for automatic/scheduled data movement to start.     
  •    
Can a cloud unit be deleted? If so how?   
         
  •         WARNING: This will destroy any data held on the cloud unit, hence the data will be unrecoverable, so proceed with caution.     
  •      
  •         Refer to the section in this knowledge base document entitled "How does a user ascertain what tier a file is located on?" to understand which files reside on the cloud unit that is going to be deleted.     
  •      
  •         These files should either be deleted if they are no longer required, or recalled to the active tier if they need to be kept.     
  •      
  •         If files need to be kept, ensure all files are recalled before continuing.     
  •      
  •         At this point, there should be no files remaining on the cloud unit that will be deleted.     
  •      
  •         Reset any data movement policies for the mtree or mtrees that use this cloud unit.     
  •      
  •         Disable the filesystem.     
  •      
  •         Delete the cloud unit. This will mark the cloud unit in a DELETE_PENDING state, which is as designed.     
  •      
  •         Enable the filesystem.     
  •      
  •         Once the filesystem has started, it will asynchronously start deleting all objects in the cloud/object storage provider that were used by this cloud unit. Once all the objects are deleted, the buckets that this cloud unit used will also be deleted. If there are a large number of objects, then the cloud unit can stay in a DELETE_PENDING state for an extended amount of time.     
  •      
  •         Once all the objects and buckets have been successfully removed, the cloud unit will disappear from the cloud unit list.     
  •    
What happens if a cloud unit fails to delete because the object storage is no longer available or there is a connectivity issue?   
         
  •         Please contact Dell EMC support for further assistance.     
  •    
Can LTR and ER (Extended Retention) be configured on the same system?   
         
  •         No. ER and LTR are mutually exclusive features.     
  •    
How is data freed or cleaned from the cloud tier?   
         
  •         Operates in a very similar fashion to files residing on the active tier.     
  •      
  •         Once a file reaches it's retention period, it will be deleted from the filesystem namespace.     
  •      
  •         Cloud tier cleaning is scheduled to run. By default cloud tier cleaning is run after every 4 active tier cleaning sessions.     
  •      
  •         For cloud tier cleaning to run, the cloud unit being cleaned must have at least 1% of superfluous/cleanable data in order to start. This is because any cloud network traffic could be chargeable so the DDR tries to limit the network traffic where possible.     
  •      
  •         Cloud tier runs with a default of 50% cleaning throttle.     
  •      
  •         Both cloud tier cleaning schedule and cleaning throttle can be changed.     
  •      
  •         Active tier and cloud tier cleaning cannot run in parallel.     
  •      
  •         If automatic/scheduled cloud tier cleaning is running, it will be pre-empted by active tier cleaning.     
  •      
  •         If a manual cloud tier clean is initiated, active tier cleaning will not be able to start until cloud tier cleaning has completed.     
  •      
  •         If a cloud tier has two cloud units, only one cloud unit will be cleaned per scheduled/automatic cloud tier clean. The cloud unit's are operated on in a round-robin fashion from a cloud tier cleaning perspective.     
  •      
  •         If a cloud tier clean fails to start on a cloud unit, for example, the current cloud unit does not have enough cleanable data to deem it worthwhile, then the system will automatically attempt to clean from the next cloud unit.     
  •      
  •         For further information regarding cloud tier cleaning, please refer to the following knowledge base article : https://support.emc.com/kb/487657     
  •    
How is a manual cloud tier clean started?   
         
  •         The command 'cloud clean start <cloud unit>' can be used. For example:     
  •    
   
      sysadmin@dd4500 # cloud clean start cloudunit2       
        Cloud tier cleaning started for cloud unit "cloudunit2". Use 'cloud clean watch' to monitor progress.
   
   
    How can a cloud tier clean be monitored?   
         
  •         The command 'cloud clean status' can be used to check if cloud cleaning is running. For example:     
  •    
   
      sysadmin@dd4500 # cloud clean status       
        Previous cloud tier cleaning attempt was unsuccessful.       
         Failure reason:       
        cloud unit "cloudunit2" did not have sufficient cleanable data.       
        Cloud tier cleaning finished at 2017/03/15 12:16:06.
   
   
         
  •         If cloud clean is currently running, it can be monitored by using the 'cloud clean watch' command.     
  •    
Can active tier cleaning run concurrently with cloud tier cleaning?   
         
  •         No. Both active tier cleaning and cloud tier cleaning both use the same common internal shared data structures which require exclusive access.     
  •    
How can a cloud tier cleaning schedule be displayed or changed?   
         
  •         To display the current cloud cleaning schedule, the command 'cloud clean frequency show' can be used. For example:     
  •    
   
      sysadmin@dd4500 # cloud clean frequency show       
        Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles.
   
   
         
  •         To change a schedule, the command 'cloud clean frequency set <value>', for example:     
  •    
   

      sysadmin@dd4500 # cloud clean frequency set 3       
        Cloud tier cleaning frequency is set to run after every 3 active tier cleaning cycles.
   

How can the cloud tier cleaning throttle be changed or displayed?   
         
  •         By default, the cloud tier cleaning throttle it set to 50%. To reset it to the default throttle percentage, the command "cloud clean throttle reset" can be used.     
  •      
  •         To display the current cloud cleaning throttle, the command 'cloud clean throttle show' can be used. For example:     
  •    
   
      sysadmin@dd4500 # cloud clean throttle show       
        Cloud tier cleaning throttle is set to 28 percent
   
   
         
  •         To change the cleaning throttle, the command 'cloud clean throttle set <value>' can be used. For example:     
  •    
   
      sysadmin@dd4500 # cloud clean throttle set 20       
        Cloud tier cleaning throttle set to 20 percent
   
   
    What does the cloud tier cleaning throttle control?   
         
  •         The cloud tier cleaning throttle operates in a similar fashion to the active tier cleaning throttle, in that throttling will limit I/O and CPU resources that the cloud tier cleaning can use.     
  •      
  •         It does not throttle network transfer.     
  •    
Why does cloud tier cleaning not free/delete as many objects as expected?   
         
  •         Cleaning is always considered an estimate. Please refer to the following knowledge base articles which describes aspects around this topic as they equally apply to data that resides on the cloud tier:      
  •    
   
      https://support.emc.com/kb/333479 - Data Domain: How to resolve issues with high space utilisation or a lack of available capacity on Data Domain Restorers (DDRs)     
      https://support.emc.com/kb/305731 - Cleanable Size is an Estimate   
   
         
  •         Further to this, there are further specific details relating to how the cloud tier is implemented.     
  •      
  •         Various methods have been implemented to limit the amount of network traffic to a cloud/object storage provider as this could come with associated costs.     
  •      
  •         As mentioned above, a minimum of 1% of data churn is required in order for clean to run.     
  •      
  •         When the filesystem is traversed to search for files that meet the data movement policy, only local copies of the metadata are examined.     
  •      
  •         Any segments held on cloud/object storage which are found to only hold user data are marked for asynchronous deletion.     
  •      
  •         Any segments containing at least one live segment are skipped because DDOS does not want to combine small amounts of data due to the network traffic involved.     
  •    
How does a user ascertain what tier a file is located on?   
         
  •         Use the command "filesys report generate file-location". An example of the output generated by this command is as follows:     
  •    
sysadmin@dd4500 # filesys report generate file-location   
    --------------------------------      ---------------------------   
    File Name                             Location(Unit Name)   
    --------------------------------      ---------------------------   
    /data/col1/mtree1/random-data-file-1        Active   
    /data/col1/mtree1/random-data-file-2        Active   
    /data/col1/mtree1/random-data-file-4        cloudunit2   
    /data/col1/mtree1/random-data-file-5        cloudunit2   
    /data/col1/mtree1/random-data-file-6        cloudunit2   
   
    Can a file be read/accessed directly after it has been migrated to the cloud tier?   
         
  •         This depends upon the version of DDOS in use along with the cloud provider:     
  •    
   
      With DDOS 6.1 and using ECS.   
   
         
  •         Directly restoring files is possible without having to recall a file first. This is known as the 'direct restore' feature and is limited to ECS as the cloud/object provider.     
  •      
  •         For more details about "direct restore" from Avamar, check the "Avamar Granular or File Level Restore from Data Domain Cloud Tier" white paper.     
  •    
   
      Otherwise:   
   
         
  •         A file has to be recalled first. That is, the data migrated back from the cloud tier to the active tier.     
  •      
  •         To allow any reads from a file or modification to a file that currently resides on the cloud tier, the file must be ‘recalled’ from the cloud tier to the active tier via the ‘data-movement recall’ command.     
  •      
  •         Any attempt to read/modify a file that resides upon the cloud tier will result in an I/O (Input/Output) error being returned to whoever tried to read the file, i.e. the backup application, if the file is not recalled first.     
  •      
  •         Some cloud aware backup applications can initiate file recalls, else files will need to be recalled manually.     
  •    
How many files can be recalled in parallel?   
         
  •         DDOS 6.0 supports 4 files to be queued and recalled in parallel.     
  •      
  •         DDOS 6.1 supports 1000 files to be queued and 4 files in the recall queue to be recalled in parallel.     
  •    
How can a file be recalled?   
         
  •         A file can be recalled by using the command 'data-movement recall path <path-name>', for example:     
  •    
   
      sysadmin@dd4500 # data-movement recall path /data/col1/mtree1/file1   
   
    How can a recall operation be monitored?   
         
  •         A recall operation can be monitored by using the command 'data-movement status path all' or if a specific file is required 'data-movement status path /data/col1/mtree/file1', for example:     
  •    
   
      sysadmin@dd4500 # data-movement status path /data/col1/mtree1/file1       
        Data-movement recall:       
        ---------------------       
        Data-movement for “/data/col1/mtree1/file1”: phase 2 of 3       
        (Verifying)       
        80% complete; time: phase XX:XX:XX total XX:XX:XX       
        Copied (post-comp): XX XX, (pre-comp) XX XX​
   
   
    Does renaming a file cause the file to be recalled from the cloud tier to the active tier?   
         
  •         No. If a file is renamed then it stays on its current tier.     
  •    
What cloud providers are supported?   
         
  •          Depending upon the DDOS version in use, DDOS supports the following cloud providers:     
  •      
  •         ​​AWS (Amazon Web Services).     
  •      
  •         Microsoft Azure Cloud.     
  •      
  •         Dell EMC ECS (Elastic Cloud Storage).     
  •      
  •         Virtustream.     
  •      
  •         Please refer to the DDOS administration guide for further information.     
  •    
Is encryption supported on the cloud tier and does it need to be licensed?   
         
  •         Yes, encryption is supported on the cloud tier. This does not require an additional license, unlike active tier encryption.     
  •      
  •         This can be configured when the cloud feature is enabled or modified after.      
  •      
  •         At the time of writing, only the embedded key manager is supported for cloud tier encryption and only one encryption algorithm can be used for LTR system wide.     
  •    
What buckets are created in the cloud providers object store?   
         
  •         DDOS will create 3 buckets.     
  •      
  •         The buckets will end with the string '-d0', '-c0' and '-m0'.     
  •      
  •         The bucket ending with the string '-d0' is used for data segments.     
  •      
  •         The bucket ending with the string '-c0' is used for configuration data.     
  •      
  •         The bucket ending with the string '-m0' is used for metadata.     
  •      
  •         Prior to DDOS 6.1, whilst 3 buckets are created, only the bucket ending '-d0' is used. However all 3 are needed so ensure they are not removed.     
  •      
  •         For more information regarding the bucket naming convention, please refer to the following knowledge base article: https://support.emc.com/kb/487833     
  •    
Is it possible to use existing bucket names that were perhaps previously created?   
         
  •         No this is not possible.     
  •    
On top of the hardware requirements, are there any other mandatory requirements that are needed prior to configuring LTR?   
         
  •         Yes.     
  •      
  •         If ECS is used, a load balancer is a mandatory requirement.     
  •      
  •         A 1Gb network between the DDR and the cloud provider.     
  •    
Are certificates required and if so, what certificates should be used?   
         
  •         This depends upon the object/cloud provider being used and also the configuration.     
  •      
  •         AWS/Virtustream/Azure will require a certificate. Please refer to the DDOS administration guide for more information.     
  •      
  •         If ECS is configured using an http endpoint, a certificate is not required.     
  •      
  •         If ECS is configured using an https endpoint, a certificate is required. As a load balancer is a mandatory requirement, the certificate required is from the loan balancer sytstem rather than the ECS system. Please contact your load balancer provider for further details.     
  •      
  •         When importing the certificate, it must be in PEM format. Some providers do not provide the certificate in the PEM format, so it must be converted prior to importing.     
  •    
What replication topologies are supported?   
         
  •         Collection replication is _not_ supported.     
  •      
  •         Directory replication is supported, however it can only be used by the '/data/col1/backup' mtree, but this mtree does not support data movement.     
  •      
  •         Mtree replication is fully supported.     
  •      
  •         MFR/VSR replication are fully supported.     
  •    
What should be considered when configuring/initialising/re-initialising replication on a system that already has LTR configured?   
         
  •         The source system will take a snapshot of the mtree (this snapshot will include details of files on active and cloud tiers).     
  •      
  •         The source system will replicate the snapshot to the active tier of destination system.     
  •      
  •         Only when the snapshot has been fully replicated will it be exposed on the destination system (at which point files become available in the destination systems filesystem namespace).     
  •      
  •         Only once files are exposed can data movement be run on the destination (assuming it is configured for LTR).     
  •      
  •         As a result if the destinations active tier is not large enough to hold a complete snapshot from the source the snapshot will never be exposed and replication cannot complete initialisation.     
  •    
What should be considered if configuring MFR/VSR replication on a system that already has LTR configured?   
         
  •         If data which has already been migrated to the cloud tier on a source DDR needs to be replicated, it will automatically be recalled from the cloud provider to the active tier before it can be sent over the network.     
  •      
  •         Recalling files from the cloud tier to active tier may incur a cost or delay.     
  •    
Why does the Data Domain 'filesystem show space' command output not reflect the actual size of the cloud/object storage?   
         
  •         Due to the inherent way that cloud/object storage works, a Data Domain system has no way to query the physical size of a cloud device as this is could be seen as being seemingly infinite.     
  •      
  •         However DDOS had to develop a way to display current usage/deduplication statistics from a DDOS perspective.     
  •      
  •         Therefore one of two approaches is used:     
  •    
   
         
  1.         The size of the cloud tier is sized by the CLOUDTIER_CAPACITY license.     
  2.      
  3.         The size of the cloud tier is shown as a multiple of active tier unit sizes for that model type depending upon how many cloud unit are configured. Refer to the hardware installation guide for the model in question for more information regarding active tier sizes.     
  4.    
How can the filesystem be started if a cloud unit is unavailable?   
         
  •         Ensure the filesystem is disabled.     
  •      
  •         Disable the cloud unit that is currently unavailable using the command 'cloud unit disable <cloud unit name>'.     
  •      
  •         Enable the filesystem.     
  •    
If a cloud unit is disabled, how can this be enabled?   
         
  •         Ensure the filesystem is disabled.     
  •      
  •         Enable the cloud unit using the command 'cloud unit enable <cloud unit name>'.     
  •      
  •         Enable the filesystem.     
  •    
Why do files still exist in the filesystem that reside on a cloud unit that was deleted?   
         
  •         ​If files were not removed from an mtree before a cloud unit was deleted, the files will continue to exist inside the filesystems namespace.     
  •      
  •         As such, the file location report will show the files are part of a deleted cloud unit, for example:     
  •    
   

      sysadmin@dd4500 # filesys report generate file-location       
        --------------------------------      ---------------------------       
        File Name                             Location(Unit Name)       
        --------------------------------      ---------------------------       
        /data/col1/mtree1/random-data-file-3  Deleted cloud-unit       
        /data/col1/mtree1/random-data-file-4  Deleted cloud-unit
   

   
         
  •         ​The files can still be seen in the filesystem namespace by accessing a CIFS/NFS share for this mtree.     
  •      
  •         However the files will not be readable because the cloud unit where they were located has been deleted.     
  •      
  •         Therefore the only option is to delete these files as their data they referenced no longer exists.     
  •    
Is it possible to change the protocol endpoint or ports for an ECS or S3 Flexible cloud provider after a cloud unit has been created?   
         
  •         For example, this maybe required if changing from http to https or vice versa, migrating to a new load balancer.     
  •      
  •         At the time of writing, there is no way for a Data Domain administrator to perform this change. This functionality is being considered for a future DDOS release.     
  •      
  •         However this can be performed by support or engineering.     
  •      
  •         Please note that the filesystem must be disabled in order to perform this change.     
  •      
  •         Please note that if this is required, it is essential that all the configuration outside of the Data Domain system is performed first because once this is changed, when the filesystem is enabled, it will expect to be able to communicate via the updated protocol/port and read the buckets/objects as it did previously.     
  •