Data Domain: Säkerhetskopieringsprogram som är inbyggda med kvarhållningslås kan få fel vid säkerhetskopiering på grund av konfigurationsproblem

Vissa säkerhetskopieringsjobb misslyckas på säkerhetskopieringsklienten med meddelanden som följande:
 

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.

I skrivskyddat läge för säkerhetskopiering och avbildningar kallas DD-backend-funktionen för den här säkerhetskopieringsprogramvaran, vilket gör att en administratör kan ställa in en tidsperiod under vilken filen i backend inte kan ändras eller tas bort, för skydd mot oavsiktlig eller skadlig databorttagning. Den här funktionen är det som kallas Data Domain Retention Lock (RL för kort).

På DD-sidan visar loggarna följande för samma lagringsenhet, underkatalog och säkerhetskopieringsfil:

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)

DD RL-konfigurationen för varje enskild MTree som har funktionen aktiverad inkluderar inställning av minsta (Retention-lock min-retention-period) och maximal (Retention-lock max-retention-period) varaktighet för lås som tillåts ställas in på någon av filerna i MTree. Med DD RL måste säkerhetskopieringsprogrammet individuellt ställa in låset på filer, såvida inte DD ARL-funktionen (Automatic Retention Lock) är aktiverad. Alternativen för MTree i exemplet var följande:
 

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
-----------------------------------------   -----------

Det innebär att för alla filer i MTree kan RL endast ställas in 720 minuter från den aktuella tiden (eller längre) och 35 dagar från den aktuella tiden (eller kortare). Med andra ord kan en fil med ovanstående konfiguration endast skyddas mot modifiering eller borttagning under en period på mer än 12 timmar, men mindre än 35 dagar. Alla försök av säkerhetskopieringsprogrammet att ställa in ett lås (vilket görs genom att uppdatera filens atime, när boost används via anropet "ddp_utime") under en kortare period eller en längre tidsperiod resulterar i felet ovan:

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.

När säkerhetskopieringsprogrammet vet hur man använder DD RL-funktionen väntar den på att säkerhetskopieringen ska slutföra skrivning till avbildningen i backend och slutligen ställa in låset på säkerhetskopian (eller bilder, eftersom vissa program kan använda mer än en fil för att lagra ett enda säkerhetskopieringsjobb). BOOST-biblioteken används för att anropa "ddp_utime" för att ställa in låset under en tidsperiod som motsvarar den avsedda kvarhållandet av säkerhetskopiering på programnivå för säkerhetskopiering. Detta har två konsekvenser:

• Om tiden inte är synkroniserad mellan säkerhetskopieringsprogrammet och DD kan säkerhetskopieringsprogrammet beräkna "X dagar från nu" och få ett datum och en tid som inte är exakt densamma som för DD, vilket skulle leda till att säkerhetskopieringsbilden låses under en kortare eller längre tidsperiod beroende på tecknet på tidsskillnaden
• Om den avsedda kvarhållandet av säkerhetskopior inte är anpassade till RL-gränserna på DD MTree kan säkerhetskopieringsprogrammet försöka ställa in ett lås för långt i framtiden (under en längre period än "Retention-lock max-retention-period") och därmed nekas inställningen av låset. Om till exempel lagringen av säkerhetskopieringsprogrammet är 60 dagar med en "Retention-lock max-retention-period" inställd på 30 dagar i DD misslyckas inställning av låset så klart

I situationer där lagringen av säkerhetskopieringsprogramvaran är lika med "Retention-Lock max-retention-period" på DD kan eventuella mindre tidsskillnader leda till att låsinställningen nekas på grund av tidsskillnaden mellan de två värdarna.

Det är viktigt att alla värdar i säkerhetskopieringsinfrastrukturen har rätt tid och därför synkroniseras de via NTP eller (om tillämpligt) Windows AD.

För att undvika hörnfall som den som beskrivs är det bra att "Retention-lock max-retention-period" i det RL-aktiverade mtree-trädet är inställt på något längre än den längsta säkerhetskopieringspolicyn som lagras i det MTree. Om datalagring till exempel är inställt på 35 dagar i säkerhetskopieringsprogrammet är inställning av "Retention-lock max-retention-period" på det DD MTree som används för att lagra dessa principer till 36 eller till och med 40 dagar det rätta att göra för att undvika oavsiktliga fel vid inställning av RL.

Observera att det inte är ett problem att ha en högre "Retention-lock max-retention-period" än kvarhållandeperioden för säkerhetskopieringsbilder. Om vi hade 100 dagar på oss att "Retention-lock max-retention-period" för en 35 dagars säkerhetskopieringspolicy tas avbildningarna bort av programmet efter 35 dagar, och rensar det använda utrymmet nästa gång det körs. Det är bara nackdelen med att av misstag ställa in avbildningar med ett längre lås. Med RL Compliance kan du inte ta bort filerna längre än förväntat. Så rekommendationen är att ange "Retention-lock max-retention-period" lite längre, men inte för mycket.