Data Domain: Problemen oplossen met hoog ruimtegebruik of een gebrek aan beschikbare capaciteit op Data Domain Restorers (DDR's)

 

• Dit is het gedeelte van de schijf waar nieuwe bestanden/data zich bevinden en op de meeste DDR's blijven bestanden hier staan totdat ze verlopen of verwijderd worden door een clientback-upapplicatie
• Op DDR's die zijn geconfigureerd met Extended Retention (ER) of Long Term Retention (LTR), kan het dataverplaatsingsproces periodiek worden uitgevoerd om oude bestanden van de actieve laag naar archief- of cloudlagen te migreren
• De enige manier om ruimte terug te winnen in de actieve laag die werd gebruikt door verwijderde/gemigreerde bestanden, is door het garbage collection/clean-proces (GC) uit te voeren

• De actieve laag kan beginnen met onvoldoende beschikbare ruimte, waardoor waarschuwingen/berichten zoals de volgende worden weergegeven:

• Als de actieve laag 100% vol raakt, kunnen er geen nieuwe data naar de DDR worden geschreven, waardoor back-ups/replicatie mislukken - in dit scenario kunnen waarschuwingen/berichten zoals de volgende worden weergegeven:

• In sommige omstandigheden kan het vol raken van de actieve laag ertoe leiden dat het Data Domain File System (DDFS) alleen-lezen wordt, waarna bestaande bestanden niet kunnen worden verwijderd.

• Uit te leggen waarom de actieve laag vol kan raken
• Een eenvoudige reeks controles te beschrijven die kunnen worden uitgevoerd om de oorzaak van een intensief gebruik van de actieve laag en de bijbehorende herstelstappen vast te stellen.

• Dit artikel is niet uitputtend (d.w.z. er kan een klein aantal situaties zijn waarin de actieve laag van een DDR in hoge mate wordt gebruikt/volraakt om een reden die niet in dit document wordt beschreven), maar het is bedoeld om de meest voorkomende oorzaken/problemen te behandelen.
• Dit artikel behandelt geen intensief gebruik van archief- of cloudlagen

  De actieve laag van een DDR kan om een aantal redenen een hoger dan verwacht gebruik ervaren.

• Back-upbestanden/storagesets worden door clientback-upapplicaties niet correct verwijderd of aangeduid als verlopen vanwege een onjuist bewaarbeleid of een onjuiste configuratie van back-upapplicatie
• Replicatievertraging waardoor een grote hoeveelheid oude data op de actieve laag wordt bewaard in afwachting van replicatie naar replica's.
• Data die naar de actieve laag worden geschreven, hebben een lagere compressiesnelheid dan verwacht
• Het systeem heeft niet de juiste grootte, d.w.z. het is gewoon te klein voor de hoeveelheid data die erop worden geschreven
• Back-ups bestaan uit een groot aantal zeer kleine bestanden - deze bestanden nemen veel meer ruimte in beslag dan verwacht bij het schrijven, maar deze ruimte moet worden teruggewonnen tijdens clean/garbage collection
• Dataverplaatsing wordt niet regelmatig uitgevoerd op systemen die zijn geconfigureerd met ER/LTR, waardoor oude bestanden die moeten worden gemigreerd naar archief-/cloudlagen op de actieve laag blijven
• Clean/garbage collection wordt niet regelmatig uitgevoerd
• Overmatige of oude mtree-snapshots die aanwezig zijn op de DDR, waardoor clean geen ruimte kan terugwinnen van verwijderde bestanden/data

Stap 1 - Bepaal of active tier clean moet worden uitgevoerd

Het Data Domain Operating System (DDOS) probeert een teller met de naam 'Cleanable GiB' bij te houden voor de actieve laag. Dit is een schatting van de hoeveel fysieke (post-comp) ruimte mogelijk kan worden teruggewonnen in de actieve laag door clean/garbage collection uit te voeren. Deze teller wordt weergegeven aan de hand van de opdrachten 'filesys show space'/'df':
 
Als een van beide het geval is:

• De waarde voor 'Cleanable GiB' is hoog
• DDFS is 100% vol geraakt (en is daarom alleen-lezen)

moet clean worden uitgevoerd en voltooid voordat u verdergaat met eventuele verdere stappen in dit document. U start de opdracht 'filesys clean start' als volgt:
 
Om te bevestigen dat clean is gestart zoals verwacht, kan de opdracht 'filesys status' worden gebruikt, d.w.z.:
 
Let op:

• Als clean niet kan worden gestart, neem dan contact op met uw gecontracteerde supportprovider voor verdere assistentie - dit kan erop wijzen dat het systeem een fout met een ontbrekend segment heeft aangetroffen waardoor clean werd uitgeschakeld
• Als clean al wordt uitgevoerd, wordt het volgende bericht weergegeven wanneer wordt geprobeerd het programma op te starten:

• Er kan geen ruimte in de actieve laag worden vrijgemaakt/teruggewonnen totdat clean de kopieerfase bereikt (standaardfase 9 in DDOS 5.4.x en ouder, fase 11 in DDOS 5.5.x en nieuwer). Voor meer informatie over de fasen die door clean worden gebruikt: https://support.emc.com/kb/446734
• Clean claimt mogelijk niet de hoeveelheid ruimte die wordt aangegeven door 'Cleanable GiB', aangezien deze waarde in wezen een schatting is. Zie voor meer informatie hierover: https://support.emc.com/kb/485637
• Clean kan mogelijk niet alle potentiële ruimte in één keer terugwinnen - dit komt omdat op DDR's met zeer grote datasets clean moet werken met het gedeelte van het bestandssysteem dat de meest overbodige data bevat (d.w.z. om het beste rendement in vrije ruimte te geven voor de tijd die nodig is om clean uit te voeren). In sommige scenario's moet clean mogelijk meerdere keren worden uitgevoerd voordat alle potentiële ruimte is teruggewonnen.
• Als de waarde voor 'Cleanable GiB' erg groot is, kan dit erop duiden dat clean niet regelmatig is uitgevoerd - controleer of er een schema voor clean is ingesteld:

Nadat clean is voltooid, gebruikt u de opdrachten 'filesys show space'/'df' om te bepalen of gebruiksproblemen zijn opgelost. Als het gebruik nog steeds hoog is, gaat u verder met de resterende stappen in dit artikel.

Stap 2 - Controleer of er een grote mate van replicatievertraging is voor de bronreplicatiecontexten

Systeemeigen Data Domain replicatie is ontworpen rond het concept van 'replicatiecontexten'. Bijvoorbeeld wanneer data moeten worden gerepliceerd tussen systemen:

• Replicatiecontexten worden gemaakt op bron- en doel-DDR's
• De contexten worden geïnitialiseerd
• Zodra de initialisatie is voltooid, verzendt replicatie periodiek updates/delta’s van bron naar bestemming om data op de systemen gesynchroniseerd te houden

Als een bron-replicatiecontext vertraging oploopt, kan dit ertoe leiden dat oude data op de harde schijf van het bronsysteem worden bewaard (merk op dat vertraagde replicatiecontexten geen overmatig gebruik op het doelsysteem kunnen veroorzaken):

• Directory-replicatiecontexten (gebruikt bij het repliceren van een enkele mapstructuur onder /data/col1/backup tussen systemen):

•  Mtree-replicatiecontexten (gebruikt bij het repliceren van een andere mtree andere dan/data/col1/backup tussen systemen):

• Verzameling-replicatiecontexten (gebruikt bij het repliceren van de volledige inhoud van een DDR naar een ander systeem):

 Om te bepalen of replicatiecontexten vertraging oplopen, moeten de volgende stappen worden uitgevoerd:

• Bepaal de hostnaam van het huidige systeem:

• Bepaal de datum/tijd op het huidige systeem:

• Maak een lijst van replicatiecontexten die op het systeem zijn geconfigureerd, samen met hun 'synced as of time'. Let op: contexten die van belang zijn, zijn die waarin de 'Destination' NIET de hostnaam van het huidige systeem bevat (wat aangeeft dat het huidige systeem de bron is) en de 'synced as of time’ aanzienlijk oud is:

Contexten waarvoor het huidige systeem de bron is en die aanzienlijke vertraging vertonen of contexten die niet langer nodig zijn, moeten worden verbroken. Dit kan worden uitgevoerd door de volgende opdracht uit te voeren op het bron- en doelsysteem:
 
Om bijvoorbeeld de hierboven getoonde 'interessante’ contexten te verbreken, zouden de volgende opdrachten op de bron en het doel moeten worden uitgevoerd:
 
Let op:

• Zodra contexten zijn verbroken, moet de active tier clean worden uitgevoerd om potentiële ruimte in de actieve laag terug te winnen
• Als u mtree-replicatie gebruikt wanneer de contexten zijn verbroken, kunnen snapshots van mtree-replicatie op de schijf blijven staan. Zorg ervoor dat 5 wordt gevolgd om overbodige snapshots te laten vervallen voordat u clean uitvoert
• Als de mtree van de bron/bestemming is geconfigureerd voor het migreren van data naar archief- of cloudlagen, moet u voorzichtig zijn bij het verbreken van overeenkomstige mtree-replicatiecontexten, aangezien deze contexten in de toekomst mogelijk niet opnieuw kunnen worden hersteld/geïnitialiseerd. De reden hiervoor is dat wanneer een mtree-replicatiecontext wordt geïnitialiseerd, er een mtree-snapshot wordt gemaakt op het bronsysteem en details bevat van alle bestanden in de mtree (ongeacht de laag). Deze snapshot wordt vervolgens volledig gerepliceerd naar de actieve laag van de bestemming. Als gevolg hiervan, als de actieve laag van de bestemming niet voldoende vrije ruimte heeft om alle mtree-data van de bron op te nemen, kan de initialisatie niet worden voltooid. Neem contact op met uw gecontracteerde supportprovider voor meer informatie over dit probleem.
• Als een verzameling-replicatiecontext is verbroken, kan de context niet opnieuw worden hersteld/geïnitialiseerd zonder eerst de instantie van DDFS op de doel-DDR te vernietigen (en alle data op dit systeem te verliezen). Als gevolg hiervan kan een volgende initialisatie veel tijd of netwerkbandbreedte in beslag nemen omdat alle data van de bron opnieuw fysiek naar de bestemming moeten worden gerepliceerd.

Stap 3 - Controleer op mtrees die niet meer nodig zijn

De inhoud van DDFS is logisch onderverdeeld in mtrees. Het is gebruikelijk voor afzonderlijke back-upapplicaties/clients om naar een afzonderlijke mtrees te schrijven. Als een back-upapplicatie buiten gebruik wordt gesteld, kan deze niet langer data schrijven naar of verwijderen uit de DDR, waardoor oude/overbodige mtrees op het systeem kunnen achterblijven. Data in deze mtrees blijven voor onbepaalde tijd bestaan en blijven schijfruimte gebruiken op de DDR. Daarom moeten dergelijke overbodige mtrees worden verwijderd. Bijvoorbeeld:

• Maak een lijst van mtrees op het systeem:

• Alle mtrees die niet meer nodig zijn, moeten worden verwijderd met de opdracht 'mtree delete’, d.w.z.:

• De ruimte die door de verwijderde mtree op de schijf wordt gebruikt, wordt teruggewonnen de volgende keer dat de active tier clean/garbage collection wordt uitgevoerd.

Let op:

• Bij mtrees die bestemmingen zijn voor mtree-replicatie (d.w.z. de status van RO/RD in de uitvoer van mtree-lijst) moet de bijbehorende replicatiecontext worden verbroken voordat de mtree wordt verwijderd.
• Mtrees die worden gebruikt als DDBoost logische storageunits (LSU’s) of als virtuele tape library (VTL)-pools kunnen mogelijk niet worden verwijderd via de 'mtree delete'-opdracht. Raadpleeg de handleiding voor Data Domain beheer voor meer informatie over het verwijderen van dergelijke mtrees
• Mtrees die zijn geconfigureerd voor retentievergrendeling (d.w.z. met de status RLCE of RLGE) kunnen niet worden verwijderd. In plaats daarvan moet de retentievergrendeling van afzonderlijke bestanden in de mtree worden teruggedraaid en afzonderlijk worden verwijderd. Raadpleeg de handleiding voor Data Domain beheer voor meer informatie

Stap 4 - Controleren op oude/overbodige mtree-snapshots

Een Data Domain snapshot vertegenwoordigt een snapshot van de bijbehorende mtree. Als gevolg daarvan:

• Alle bestanden die in de mtree aanwezig zijn op het moment dat de snapshot wordt gemaakt, worden door de snapshot gerefereerd
• Terwijl de snapshot blijft bestaan, zelfs als deze bestanden worden verwijderd, kan clean geen fysieke ruimte terugwinnen die ze op de schijf gebruiken - dit komt omdat de data op het systeem moeten blijven voor het geval de kopie van het bestand in de snapshot later wordt geopend

Om te bepalen of mtrees oude/overbodige snapshots hebben, moeten de volgende stappen worden uitgevoerd:

• Maak een lijst met mtrees op het systeem met behulp van de 'mtree list'-opdracht zoals weergegeven in stap 3
• Maak een lijst van snapshots die voor elke mtree bestaan met behulp van de 'snapshot list'-opdracht:

• Waar snapshots bestaan, gebruikt u de uitvoer van 'snapshot list mtree [mtree name]’ om snapshots te bepalen die:

• Als de ‘snapshot list'-opdracht opnieuw wordt uitgevoerd, worden deze snapshots nu weergegeven als verlopen:

Let op:

• Het is niet mogelijk om te bepalen hoeveel fysieke data een individuele snapshot of verzameling snapshots op de schijf bevat - de enige waarde voor 'ruimte' die aan een snapshot is gekoppeld, is een indicatie van de voorgecomprimeerde (logische) grootte van de mtree toen de snapshot werd gemaakt (zoals weergegeven in de bovenstaande uitvoer)
• Snapshots met de naam 'REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS' worden beheerd door mtree-replicatie en hoeft u deze onder normale omstandigheden niet handmatig te laten vervallen (replicatie zal deze snapshots automatisch laten verlopen wanneer ze niet meer nodig zijn). Als dergelijke snapshots extreem oud zijn, geeft dit aan dat de bijbehorende replicatiecontext waarschijnlijk een aanzienlijke vertraging vertoont (zoals beschreven in stap 2).
• Snapshots met de naam 'REPL-MTREE-RESYNC-RESERVE-YYYY-MM-DD-HH-MM-SS' worden gemaakt door mtree-replicatie wanneer een mtree-replicatiecontext wordt verbroken. De bedoeling ervan is dat ze kunnen worden gebruikt om een ​​volledige hersynchronisatie van replicatiedata te voorkomen als de verbroken context later opnieuw wordt hersteld (bijvoorbeeld als de context per ongeluk is verbroken). Als replicatie niet wordt hersteld, kunt u deze contexten niet meer handmatig laten verlopen, zoals hierboven beschreven.
• Verlopen snapshots blijven op het systeem bestaan ​​tot de volgende keer dat clean/garbage collection wordt uitgevoerd - op dit punt worden ze fysiek verwijderd en verwijderd uit de uitvoer van 'snapshot list mtree [mtree name]' - clean kan dan elke ruimte terugwinnen die deze snapshots op de schijf gebruiken

Stap 5 - Controleer of er een onverwacht aantal oude bestanden op het systeem is

Autosupports van de DDR bevatten histogrammen met een uitsplitsing van bestanden op de DDR naar ouderdom, bijvoorbeeld:
 
Dit kan handig zijn om te bepalen of er bestanden op het systeem aanwezig zijn die niet zijn verlopen of verwijderd zoals verwacht door de clientback-upapplicatie. Als bijvoorbeeld naar het bovenstaande systeem is geschreven door een back-upapplicatie waarbij de maximale retentieperiode voor een bestand 6 maanden was, is het direct duidelijk dat de back-upapplicatie geen laat verlopen/verwijderen zoals verwacht, aangezien er ongeveer 80.000 bestanden ouder zijn dan 6 maanden op de DDR.

Let op:

• Het is de verantwoordelijkheid van de back-upapplicatie om alle bestanden te laten verlopen/verwijderen
• Een DDR zal nooit bestanden automatisch laten verlopen/verwijderen, tenzij de back-upapplicatie opdracht geeft om expliciet een bestand te verwijderen, blijft het bestand op de DDR staan met gebruik van ruimte voor onbepaalde tijd

Daarom moeten problemen als deze eerst worden onderzocht door het supportteam van de back-upapplicatie.

Indien nodig kan Data Domain support aanvullende rapporten verstrekken aan:

• Geef de naam/wijzigingstijd op van alle bestanden op een DDR geordend op ouderdom (zodat de naam/locatie van eventuele oude data kan worden bepaald)
• Splits histogrammen van bestandsouderdom op in afzonderlijke rapporten voor de actieve/archief-/cloudlaag (waarbij de ER/LTR-functies zijn ingeschakeld)

Dit kunt u als volgt doen:

• Verzamel bewijsmateriaal zoals beschreven in de alinea 'sfs_dump verzamelen' van het gedeelte Opmerkingen van dit document
• Open een serviceaanvraag met uw gecontracteerde supportprovider

Nadat de oude/overbodige bestanden zijn verwijderd, moet active tier clean/garbage collection worden uitgevoerd om ruimte fysiek terug te winnen in de actieve laag

Stap 6 - Controleer op back-ups met een groot aantal kleine bestanden

Vanwege het ontwerp van DDFS kunnen kleine bestanden (in wezen elk bestand dat kleiner is dan ongeveer 10 MB) buitensporig veel ruimte in beslag nemen wanneer ze in eerste instantie naar de DDR worden geschreven. Dit komt door de 'SISL'-architectuur (Stream Informed Segment Layout) die ervoor zorgt dat kleine bestanden meerdere individuele blokken van 4,5 MB aan schijfruimte in beslag nemen. Een 4Kb-bestand kan bijvoorbeeld in eerste instantie tot 9 MB fysieke schijfruimte in beslag nemen

Deze overtollige ruimte wordt vervolgens teruggewonnen wanneer clean/garbage collection wordt uitgevoerd (omdat data van kleine bestanden vervolgens worden samengevoegd tot een kleiner aantal blokken van 4,5 MB), maar kan ervoor zorgen dat kleinere modellen van DDR overmatig worden gebruikt en worden gevuld wanneer dergelijke back-ups worden uitgevoerd.

Autosupports bevatten histogrammen van bestanden opgesplitst naar grootte, bijvoorbeeld:
 
Als er aanwijzingen zijn dat back-ups zeer grote aantallen kleine bestanden schrijven, kan het systeem worden beïnvloed door een aanzienlijke tijdelijke toename van het gebruik tussen elke aanroep van clean/garbage collection. In dit scenario verdient het de voorkeur om de back-upmethodologie te wijzigen om alle kleine bestanden op te nemen in een enkel groter archief (zoals een tar-bestand) voordat ze naar de DDR worden geschreven. Merk op dat een dergelijk archief niet mag worden gecomprimeerd of versleuteld (omdat hierdoor de compressiesnelheid/de-duplicatieverhouding van die data wordt beschadigd).

Stap 7 - Controleer of de de-duplicatieverhouding lager is dan verwacht

Het belangrijkste doel van een DDR is de-duplicatie en comprimeren van data die door het apparaat worden opgenomen. De verhouding tussen de-duplicatie/compressie is sterk afhankelijk van het gebruik van het systeem en het type data dat het bevat, maar in veel gevallen zal er een 'verwachte' algehele compressiesnelheid zijn op basis van resultaten die zijn verkregen door middel van een haalbaarheidstest of vergelijkbare methode. Om de huidige algehele compressiesnelheid van het systeem te bepalen (en dus of het aan de verwachtingen voldoet) kan het commando 'filesys show compressie' worden gebruikt. Bijvoorbeeld:
 
In bovenstaande voorbeeld bereikt het systeem een algehele compressiesnelheid van 65,3x voor de actieve laag (dit is bijzonder goed). Als deze waarde echter aangeeft dat de algehele compressiesnelheid niet aan de verwachtingen voldoet, is nader onderzoek waarschijnlijk nodig. Merk op dat het onderzoeken van een lager dan verwachte compressiesnelheid een complex onderwerp is dat vele hoofdoorzaken kan hebben. Zie het volgende artikel voor meer informatie over zo'n onderzoek: 
https://support.emc.com/kb/487055
Stap 8 - Controleer of het systeem een bron is voor verzameling-replicatie

Bij gebruik van verzameling-replicatie als het bronsysteem fysiek groter is dan de bestemming, wordt de grootte van het bronsysteem kunstmatig beperkt tot die van de bestemming (d.w.z. er zal een schijfgedeelte op de bron zijn dat als onbruikbaar wordt gemarkeerd). De reden hiervoor is dat bij het gebruik van verzameling-replicatie de bestemming een kopie van de bron moet zijn als de bron indien fysiek groter dan de bestemming is, de kans bestaat dat er te veel data naar de bron worden geschreven die dan niet naar de bestemming kunnen worden gerepliceerd (omdat deze al vol is). Dit scenario wordt voorkomen door de grootte van de bron te beperken zodat deze overeenkomt met de bestemming.

• Controleer met behulp van de opdrachten van stap 2 of het systeem een bron is voor replicatie van verzamelingen. Voer hiervoor 'replication status’ uit en bepaal of er replicatiecontexten zijn die beginnen met 'col://' (geeft verzameling-replicatie aan) die NIET de hostnaam van het lokale systeem in de bestemming bevat (wat aangeeft dat dit systeem een bron moet zijn voor de replicatiecontext)
• Als het systeem een bron is voor verzameling-replicatie, controleer dan de grootte van de actieve laag van elk systeem door u op beide aan te melden en de opdracht 'filesys show space' uit te voeren - vergelijk de grootte van ‘post-comp’ van de actieve lagen op elk
• Als de bron aanzienlijk groter is dan de bestemming, zal de actieve laaggrootte ervan kunstmatig worden beperkt.
• Om ervoor te zorgen dat alle ruimte op de bron bruikbaar is voor data, moet het volgende worden uitgevoerd:

Stap 9 - Controleer of dataverplaatsing regelmatig wordt uitgevoerd

Als de DDR is geconfigureerd met Extended Retention (ER) of Long Term Retention (LTR), is er een tweede storagelaag aan gekoppeld (archieflaag voor ER of cloudlaag voor LTR). In dit scenario is beleid voor dataverplaatsing waarschijnlijk geconfigureerd op mtrees om oudere/ongewijzigde data te migreren die langdurig moeten worden bewaard van de actieve laag naar de alternatieve storagelaag, zodat de ruimte die door deze bestanden in de actieve laag wordt gebruikt, fysiek kan worden teruggewonnen door clean/garbage collection. Als het beleid voor dataverplaatsing onjuist is geconfigureerd of als het dataverplaatsingsproces niet regelmatig wordt uitgevoerd, blijven oude data langer dan verwacht in de actieve laag en blijven ze fysieke ruimte op de schijf gebruiken.

• Bevestig in eerste instantie of het systeem is geconfigureerd voor ER of LTR door 'filesys show space' uit te voeren en te controleren op het bestaan ​​van een archief- of cloudlaag - houd er rekening mee dat deze alternatieve storagelagen een post-comp-grootte van > 0 Gb moeten hebben om bruikbaar te zijn:

• Als het systeem is geconfigureerd met ER/LTR, controleer dan het beleid voor dataverplaatsing op mtrees om ervoor te zorgen dat deze zijn zoals verwacht en stel ze zo in dat oude data naar de alternatieve storagelaag worden geduwd:

• Als het systeem is geconfigureerd met ER/LTR, controleer dan of de dataverplaatsing is gepland om met regelmatige tussenpozen te worden uitgevoerd om bestanden/data fysiek van de actieve laag naar alternatieve storage te migreren:

• Als het systeem is geconfigureerd voor ER/LTR, controleer dan de laatste keer dat dataverplaatsing werd uitgevoerd:

• Zodra de dataverplaatsing is voltooid, moet active tier clean worden uitgevoerd (merk op dat het kan worden geconfigureerd om automatisch te starten na voltooiing van de dataverplaatsing) om ervoor te zorgen dat de ruimte die wordt gebruikt door mijn gemigreerde bestanden in de actieve laag fysiek wordt vrijgemaakt:

Stap 10 - Voeg extra storageruimte toe aan de actieve laag

Als alle voorgaande stappen zijn uitgevoerd, active tier clean is voltooid, maar er is nog steeds onvoldoende ruimte beschikbaar op de actieve laag, dan heeft het systeem waarschijnlijk niet de juiste grootte voor de workload die het ontvangt. In dit geval moet een van de volgende handelingen worden uitgevoerd:

• Verlaag de workload van het systeem, bijvoorbeeld:

• Voeg extra storageruimte toe aan de actieve laag van het systeem en breid de grootte ervan uit:

Data Domain support kan een aantal rapporten genereren met informatie zoals:

• Een lijst met alle bestanden in een bepaalde laag (d.w.z. actief/archief/cloud) gerangschikt op ouderdom
• Geschatte grootte en compressiesnelheid per mtree/hoofddirectorystructuur
• Een lijst met alle bestanden in een bepaalde mtree gerangschikt op ouderdom
• enzovoort

Om dit mogelijk te maken, moet de volgende informatie worden verzameld:

• Een verse supportbundel vanuit de DDR - zie het volgende artikel voor meer informatie: https://support.emc.com/kb/323283
• De uitvoer van 'sfs_dump' of 'sfs_dump -c':

• Een bestandslocatierapport (vereist als het systeem is geconfigureerd voor ER of LTR):

Voor hulp bij het verzamelen van het bovenstaande of bij een van de stappen in deze archive clean, kunt u contact opnemen met uw gecontracteerde supportprovider.