Data Domain: Back-upapplicatie geïntegreerd met Retention Lock kan back-upfouten ondervinden als gevolg van een configuratieprobleem

Sommige back-uptaken mislukken op de back-upclient met berichten zoals:
 

8212 6df7 12/05 15:47:15 871396 [MEDIAFS    ] 3637866-3138214 Cannot set the access time of [/data/col1/Commvault/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307], error=0xECCC000D:{CQiFile::SetTimes(825)/ErrNo.13.(Permission denied)}
8212 6df7 12/05 15:47:15 871396 [MEDIAFS    ] 3637866-3138214 Cannot mark the file [/data/col1/Commvault/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307] as read only.

De 'alleen-lezen'-modus voor back-ups en images is hoe deze specifieke back-upsoftware de DD-back-endfunctie aanroept waarmee een beheerder een periode kan instellen waarin het bestand in de back-end mogelijk niet kan worden gewijzigd of verwijderd, voor bescherming tegen accidentele of schadelijke dataverwijdering. Deze functie wordt de Data Domain Retention Lock (RL) genoemd.

Aan de DD-kant geven logboeken het volgende weer voor dezelfde storage-eenheid, subdirectory en back-upbestand:

12/05 07:47:47.820284 [7f1bc842a000] Attempt to set atime of 16adcf:0:16addb:0:7d70db86:6256fe81:0 to larger than maximum retention period of mtree.
12/05 07:47:47.820289 [7f1bc842a000] ERROR: FM fm_dm1_setattr:1408 - fm_dm1_setattr_intern failed
12/05 07:47:47.820533 [7f1bcdf19d90] ddboost-: ddboost_api ERROR: ddp_utime() failed, su_name=Commvault, path_name=/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307, Err: 5034-nfs setattr failed (nfs: Permission denied)

De DD RL-configuratie voor elke afzonderlijke MTree waarvoor de functie is ingeschakeld, omvat het instellen van de minimale (Retention-lock min-retention-period) en de maximale (Retention-Lock max-retention-period) duur van vergrendelingen die mogen worden ingesteld op een van de bestanden in de MTree. Met DD RL moet de back-upapplicatie de vergrendeling op bestanden afzonderlijk instellen, tenzij de functie DD Automatic Retention Lock (ARL) is ingeschakeld. De opties voor de MTree in het voorbeeld waren als volgt:
 

Mtree: /data/col1/Commvault

Option                                      Value
-----------------------------------------   -----------
Retention-lock                              enabled
Retention-lock mode                         governance
Retention-lock uuid                         UUID1:UUID2
Retention-lock min-retention-period         720minutes
Retention-lock max-retention-period         35days
Retention-lock automatic-retention-period   not set
Retention-lock automatic-lock-delay         120minutes
Retention-lock indefinite-retention-hold    disabled
-----------------------------------------   -----------

Dit betekent dat voor elk bestand in de MTree de RL slechts 720 minuten mag worden ingesteld op de huidige tijd (of langer) en 35 dagen vanaf de huidige tijd (of korter). Met andere woorden, met de bovenstaande configuratie kan een bestand alleen worden beschermd tegen wijzigingen of verwijdering gedurende een periode van meer dan 12 uur, maar minder dan 35 dagen. Elke poging van de back-upapplicatie om een vergrendeling in te stellen (dit wordt gedaan door het bijwerken van de atime van het bestand, bij gebruik van BOOST, via de "ddp_utime"-oproep) voor een kortere of langere duur zal resulteren in de hierboven weergegeven fout:

12/05 07:47:47.820284 [7f1bc842a000] Attempt to set atime of 16adcf:0:16addb:0:7d70db86:6256fe81:0 to larger than maximum retention period of mtree.

Wanneer de back-upapplicatie weet hoe de DD RL-functie moet worden gebruikt, wacht de back-up tot het schrijven naar de image in de back-end is voltooid en wordt uiteindelijk de vergrendeling op de back-upimage ingesteld (of images, omdat sommige software mogelijk meer dan één bestand gebruikt om één back-uptaak op te slaan). De BOOST-bibliotheken worden gebruikt om de "ddp_utime" te noemen om de vergrendeling in te stellen voor een duur die gelijk is aan de beoogde back-upretentie op het niveau van de back-uptoepassing. Dit heeft twee gevolgen:

• Als de tijd niet synchroon loopt tussen de back-upapplicatie en de DD, kan de back-upapplicatie "X dagen vanaf nu" berekenen en een datum en tijd verkrijgen die niet precies hetzelfde is als die voor de DD, wat ertoe zou leiden dat de back-upimage gedurende een kortere of langere periode is vergrendeld, afhankelijk van het teken van het tijdsverschil
• Als de beoogde back-upretentie niet is afgestemd op de RL-limieten op de DD MTree, kan de back-upapplicatie in de toekomst proberen een vergrendeling te ver in te stellen (gedurende een periode langer dan "Retention-lock max-retention-period") en wordt de instelling van de vergrendeling geweigerd. Als de bewaarperiode van de back-upapplicatie bijvoorbeeld 60 dagen is met een 'Retention-lock max-retention-period' ingesteld op 30 dagen in de DD, zal het instellen van de vergrendeling natuurlijk mislukken

In situaties waarin de bewaarperiode van de back-upsoftware gelijk is aan de 'Retention-lock max-retention-periode' op de DD, kunnen kleine tijdsverschillen ertoe leiden dat de vergrendelingsinstelling wordt geweigerd vanwege het tijdsverschil tussen de twee hosts.

Het is belangrijk dat alle hosts in de back-upinfrastructuur de juiste tijd hebben en daarom synchroniseren via NTP of (indien van toepassing) Windows AD.

Om hoekscenario's te voorkomen, zoals beschreven, is het een goede gewoonte dat de 'Retention-lock max-retention-period' in de MTree met RL iets langer is dan het langst bewaarde back-upbeleid dat in die MTree is opgeslagen. Als dataretentie bijvoorbeeld is ingesteld op 35 dagen in back-upapplicatie, is het instellen van de "Retention-lock max-retention-periode" op de DD MTree die wordt gebruikt om deze policy's op te slaan in 36 of zelfs 40 dagen het juiste om te doen om onbedoelde fouten bij het instellen van RL te voorkomen.

Opmerking: het hebben van een 'Retention-lock max-retention-period' hoger dan de bewaarperiode voor back-upimages is geen probleem. Als we 100 dagen "Retention-lock max-retention-period" hadden voor een bewaarperiode van 35 dagen, worden de images na 35 dagen verwijderd door de applicatie en zal Clean de gebruikte ruimte de volgende keer dat deze wordt uitgevoerd afvoeren. Het enige nadeel is dat bij het per ongeluk instellen van images met een langere vergrendeling, met RL Compliance, u de bestanden niet langer kunt verwijderen dan verwacht. De aanbeveling is dus om "Retention-lock max-retention-period" iets langer in te stellen, maar niet te veel.