Symptoms
Noen sikkerhetskopieringsjobber mislykkes på sikkerhetskopieringsklienten med meldinger som følgende:
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.
Skrivebeskyttet modus for sikkerhetskopiering og imager er måten denne bestemte programvaren for sikkerhetskopiering kaller funksjonen DD-serverserver som gjør det mulig for en administrator å angi en tidsperiode der filen i serverserveren ikke kan endres eller slettes, for beskyttelse mot utilsiktet eller skadelig sletting av data. Denne funksjonen kalles Data Domain Retention Lock (RL for kort tid).
På DD-siden viser loggene følgende for samme lagringsenhet, underkatalog og sikkerhetskopifil:
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)
Cause
DD RL-konfigurasjonen for hvert enkelt MTree som har funksjonen aktivert, inkluderer å angi minstevarigheten (Retention-lock min-retention-period) og maksimal (retention-lock max-retention-period) for låser som kan angis på en av filene i MTree. Med DD RL må sikkerhetskopieringsapplikasjonen angi låsen på filer individuelt, med mindre DD Automatic Retention Lock-funksjonen (ARL) er aktivert. Alternativene for MTree i eksemplet var som følger:
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
----------------------------------------- -----------
Dette betyr at RL bare kan angis 720 minutter fra gjeldende tid (eller lenger) og 35 dager fra gjeldende tid (eller kortere) for alle filer i MTree. Med andre ord, med konfigurasjonen ovenfor kan en fil bare være beskyttet mot endring eller fjerning i en periode på mer enn 12 timer, men mindre enn 35 dager. Alle forsøk fra sikkerhetskopieringsapplikasjonen for å angi en lås (som gjøres ved å oppdatere filens atime, når du bruker BOOST, via "ddp_utime"-anropet) i en kortere eller lengre varighet, vil resultere i feilen som vises ovenfor:
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 sikkerhetskopieringsapplikasjonen vet hvordan du bruker DD RL-funksjonen, venter den på at sikkerhetskopieringen skal fullføre skrivingen til imaget i serverserveren, og deretter til slutt angi låsen på sikkerhetskopiimaget (eller bilder, ettersom noen programvarer kan bruke mer enn én fil til å lagre én enkelt sikkerhetskopieringsjobb). BOOST-bibliotekene vil bli brukt til å ringe "ddp_utime" for å angi låsen i en varighet som tilsvarer den tiltenkte sikkerhetskopilagringen på nivået for sikkerhetskopieringsapplikasjonen. Dette har to konsekvenser:
- Hvis klokkeslettet ikke er synkronisert mellom sikkerhetskopieringsapplikasjonen og DD, kan sikkerhetskopieringsapplikasjonen beregne X dager fra nå og hente en dato og et klokkeslett som ikke er nøyaktig det samme som for DD, noe som vil føre til at sikkerhetskopibildet er låst i en kortere eller lengre periode, avhengig av tegnet på tidsforskjellen
- Hvis den tiltenkte sikkerhetskopieringslagringen ikke er justert etter RL-grensene på DD MTree, kan det hende at sikkerhetskopieringsapplikasjonen prøver å sette en lås for langt frem i fremtiden (i en periode som er lengre enn "Max-retention-period") for oppbevaringslås), og dermed vil innstillingen for låsen bli nektet. Hvis for eksempel sikkerhetskopieringsapplikasjonen er 60 dager med "Retention-lock max-retention-period" angitt til 30 dager i DD, vil innstillingen av låsen selvsagt mislykkes
I situasjoner der oppbevaring av sikkerhetskopieringsprogramvaren tilsvarer "retention-lock max-retention-period" på DD, kan eventuelle mindre tidsforskjeller føre til at låseinnstillingen blir nektet på grunn av tidsforskjellen mellom de to vertene.
Resolution
Det er viktig at alle verter i sikkerhetskopieringsinfrastrukturen har riktig tid, og derfor at de synkroniserer via NTP eller (hvis aktuelt) Windows AD.
For å unngå hjørnetilfeller, for eksempel den som beskrives, er det god praksis at "Retention-lock max-retention-period" i RL-aktiverte MTree er satt til litt lenger enn den lengst beholdte sikkerhetskopipolicyen som er lagret i MTree. Hvis for eksempel datalagring er satt til 35 dager i en sikkerhetskopiapplikasjon, er det riktig å angi "Retention-lock max-retention-period" på DD MTree som brukes til å lagre disse policyene til 36 eller til og med 40 dager, for å unngå utilsiktede feil ved å angi RL.
Vær oppmerksom på at det ikke er et problem å ha en "oppbevaringslås med maksimal oppbevaringsperiode" høyere enn oppbevaringsperioden for sikkerhetskopiimage. Hvis vi hadde 100 dager med "Oppbevaringslås maks. oppbevaringsperiode" i 35 dager med sikkerhetskopiering etter 35 dager, vil imagene bli slettet av applikasjonen, og rengjør vil avhende brukt plass neste gang det kjøres. Det er bare en ulempe med utilsiktet innstilling av imager med en lengre lås, med RL-samsvar, at du ikke vil kunne slette filene lenger enn forventet. Anbefalingen er derfor å angi "Retention-lock max-retention period" litt lenger, men ikke for mye.
Affected Products
Data Domain