The customer wants five years of monthly backup copies retained on cheaper storage and asks what the appliance design must include right now to make that work. What is the correct pre-deployment answer?
Select an answer to reveal the explanation.
Short Explanation
Keeping five years of monthly copies on primary disk is like carrying every grocery receipt in your wallet. Cloud Tier moves those long-term copies to much cheaper object storage, but the store, its licensing, and the network path to it have to exist in the design before they can exist in production. Add them on paper today or the cheap archive stays imaginary.
Full Explanation
Long-term, infrequently accessed copies are the exact use case for Cloud Tier: DD OS moves aged backup data from the active pool to an object-store target—private or public object storage—while the file system continues to present the data as local so searches and restores still work. Making that real requires design-time work: sizing how much archive capacity five years of monthly copies will occupy, obtaining the licensing that enables the feature, and standing up network connectivity and credentials that reach the object store. Promising a later free pivot to any object store fails by concept because licensing gates the capability and connectivity plus target capacity are physical prerequisites no retroactive pointer can invent. Buying additional local disks fails the customer's stated economics, because primary capacity is precisely the expensive tier the requirement wants to escape. Restricting five-year retention to VTL fails because retention length is not tied to tape emulation when disk tiering addresses this pattern directly. Exam caveat: lifecycle and retention rules apply to tiered data differently than to active-pool data, so the movement policy belongs in the design document. Operational check: total the projected archive footprint across the five-year horizon, confirm the object store bucket and access path exist, and record the license part number on the order.