Data Domain: Vanlige spørsmål om oppbevaringslås

Hva er en festelås?
Oppbevaringslås er en funksjon som brukes på Data Domain Restorers (DDR-er) for å hindre endring eller sletting av bestemte filsett i en forhåndsbestemt periode. Det vil si at låste oppbevaringsfiler er skrivebeskyttet til oppbevaringsperioden utløper.

Hva er de forskjellige versjonene av festelås?
Oppbevaringslås er tilgjengelig for to forskjellige funksjoner:

• Styresett: Den mindre strenge av de to oppbevaringslåsfunksjonene (det vil si låser mot filer, kan tilbakestilles om nødvendig).
• Samsvar: Den strengeste av de to funksjonene som følger flere felles forskriftsmessige standarder. Det vil si at låser mot filer ikke kan tilbakestilles. DDR må konfigureres med en "sikkerhetsansvarlig"-bruker som må godkjenne visse kommandoer. Det finnes ulike begrensninger på annen funksjonalitet for å hindre at låste data fjernes eller at låser tilbakestilles tidlig.

Hvilke datatilgangsprotokoller støttes med oppbevaringslås?

• NFS-, CIFS- og DD Boost-protokollene støttes fullt ut mot MTrees ved hjelp av styring av oppbevaringslås eller samsvarsmodus.
• VTL-protokollen (Virtual Tape Library) støttes bare mot MTrees ved hjelp av styringsmodus for oppbevaringslås. Automatisk oppbevaringslås støttes ikke på Data Domain VTL. Se Data Domain Administration Guide for å finne ut hvordan du låser opp oppbevaringslåste bånd slik at de kan skrives til.

Modus for overholdelse av oppbevaringslås oppfyller forskriftsmessige standarder:
Listen over forskriftsmessige standarder som samsvarsmodus for oppbevaringslås oppfyller inkluderer følgende:     

• SEC 17a-4(f)
• CFTC-regel 1.31b
• FDA 21 CFR Del 11
• Sarbanes-Oxley-loven
• IRS 98025 og 97-22
• ISO-standard 15489-1
• MoREQ2010

Hvis du vil ha fullstendig informasjon om sertifisering, kan du kontakte den avtalte støtteleverandøren.

Hvordan aktiveres styring av oppbevaringslås?

• En styringslisens for oppbevaringslås legges til DDR.
• Styringsmodus for oppbevaringslås er aktivert mot alle påkrevde MTree:     

# mtree retention-lock enable mode governance mtree [mtree]

Hvordan aktiveres overholdelse av oppbevaringslås?

• Det finnes spesifikke instruksjoner for noen nyere Data Domain-modeller med iDRAC.
• En samsvarslisens for oppbevaringslås legges til DDR.
• En bruker med rollen "sikkerhet" bør opprettes (forutsatt at en slik bruker ikke eksisterer):     

(ADMIN USER) # user add [username] role security

•  Brukeren med rollen "sikkerhet" bør logge på DDR og aktivere sikkerhetsbrukerautorisasjon:     

(SECURITY USER): # authorization policy set security-officer enabled

• Systemet bør konfigureres for modus for overholdelse av oppbevaringslås. Når følgende kommando fullføres, starter systemet på nytt automatisk:     

(ADMIN USER) # system retention-lock compliance configure

• Når systemet har startet på nytt, skal modus for overholdelse av oppbevaringslåsing være aktivert på systemet:     

(ADMIN USER) # system retention-lock compliance enable

• Modus for overholdelse av oppbevaringslås er aktivert mot alle påkrevde MTree:

(ADMIN USER) # mtree retention-lock enable mode compliance mtree [mtree]

Hvordan er det mulig å finne ut hvilken MTrees som har festelås aktivert?
MTrees med festelås aktivert er angitt i utdataene fra mtree listfor eksempel:

sysadmin@ddxxxx# mtree list
Name                                Pre-Comp (GiB)   Status    Tenant-Unit
---------------------------------   --------------   -------   -----------
...
/data/col1/rich-retention-lock                 0.0   RW/RLGE   -
/data/col1/rl_test                             0.0   RW/RLGD   -
/data/col1/rl_test_comp                        0.0   RW/RLCE   -
/data/col1/test                                3.1   RW/RLGE   -
...
---------------------------------   --------------   -------   -----------
...
 RLGE : Retention-Lock Governance Enabled
 RLGD : Retention-Lock Governance Disabled
 RLCE : Retention-Lock Compliance Enabled

Kan et MTree med styring av oppbevaringslås aktivert konverteres til samsvar med oppbevaringslås?
Som nevnt i DDOS Administration Guide, er dette ikke mulig.

Kan et MTree med samsvar med oppbevaringslås aktivert konverteres til styring av oppbevaringslås?
Som nevnt i DDOS Administration Guide, er dette ikke mulig.

Hvordan angis filoppbevaring eller låseperioder?
Når en oppbevaringslås er aktivert mot et MTree, må du angi en minimum og maksimum oppbevaringsperiode. Disse periodene dikterer minimums- og maksimumstiden en fil i MTree kan låses for. Eksempel:     

# mtree retention-lock set min-retention-period [period] mtree [mtree]
# mtree retention-lock set max-retention-period [period] mtree [mtree]

Perioder kan gis i ulike enheter som følger:     

• 1 min
• 1 time
• 1 dag
• 1 mnd.
• 1 år

Hvordan kan eksisterende oppbevaringsperioder vises?
Dette kan gjøres ved å bruke følgende to kommandoer:     

# mtree retention-lock show min-retention-period mtree [mtree]
# mtree retention-lock show max-retention-period mtree [mtree]

Eksempel:     

sysadmin@dd630# mtree retention-lock show min-retention-period mtree /data/col1/rl_test
Retention-lock min-retention-period of mtree /data/col1/rl_test is: 720 minutes.
sysadmin@dd630# mtree retention-lock show max-retention-period mtree /data/col1/rl_test
Retention-lock max-retention-period of mtree /data/col1/rl_test is: 30 days.

Hvordan er filer i et MTree med oppbevaringslås aktivert låst?

• Når oppbevaringslås er aktivert mot et MTree, låses ikke eksisterende filer i MTree automatisk (det vil si at alle eksisterende filer forblir lest eller skrevet).
• Når en ny fil skrives til et MTree med lagringslås aktivert, låses ikke filen automatisk. Det vil si at den nye filen forblir som lest eller skrevet.

• Hvis du vil låse en bestemt fil, må tidspunktet for filen endres slik at den samsvarer med datoen og tidspunktet for at oppbevaringslåsen for filen skal være låst. Det er datoen og klokkeslettet som filen skal forbli skrivebeskyttet. Inntil tiden er endret på denne måten, kan filen ikke oppbevaringslåst (og kan endres eller fjernes).

En fils tid kan endres fra en NFS- eller CIFS-klient ved hjelp av kommandoen 'touch':

# touch -a -t [expiry time] [file to be locked]

For eksempel, for å angi tid på /data/col1/rl_test/testfile til 07.05 den 8. 

# touch -a -t 06080705 /data/col1/rl_test/testfile

Perioden fra nåværende tid til fremtidig tid må være innenfor minimums- og maksimumsoppbevaringsperiodene for MTree. Ellers genereres det en feil når du endrer filene atime:

# touch -a -t 08080705 /data/col1/rl_test/testfile
touch: setting times of `/data/col1/rl_test/testfile': Permission denied

En tilsvarende melding vises også i loggfilene for Data Domain File System (DDFS):

06/07 13:44:57.197 (tid 0x2b28ee5258c0): Attempt to set atime of /data/col1/rl_test/testfile to larger than maximum retention period of mtree.

CIFS (Windows)-klienter inkluderer som standard ikke en berøringskommando eller et verktøy, men flere slike verktøy er fritt tilgjengelige for nedlasting fra forskjellige tredjeparts nettsteder.

Hvilke sikkerhetskopieringsprogrammer støtter automatisk oppbevaring av låsefiler etter at de er skrevet til en DDR?
Data Domain Retention Lock er kompatibel med bransjestandardiserte NAS-baserte Write-Once-Read-Many (WORM)-protokoller. Integrering er kvalifisert med arkivprogrammer som Symantec Enterprise Vault, SourceOne, Cloud Tiering Appliance eller DiskXtender.

For Dell NetWorker støttes både styrings- og overholdelsesmoduser.

Fra juni 2024 støtter nyere Avamar-versjoner både samsvar med oppbevaringslås for datadomenet og styring) som en del av Avamars «Immutable Backups»-funksjon. Se artikkelen nedenfor og Avamar-dokumentasjonen for mer informasjon:
Avamar og Data Domain: Aktivering av uforanderlige sikkerhetskopier og oppbevaringslås for oppbevaringslås

for overholdelseslås for datadomenemodusDet er viktig at trinnene for å aktivere Avamars "Immutable Backups"-funksjon følges nøye. Hvis du ikke gjør dette, kan det ende opp med en Avamar MTree i DD som ikke kan skrives videre til, eller som har driftsproblemer som tvinger frem langvarig gjenoppretting. Avamar fungerer ikke med automatisk DD-lås (ARL), og ARL må ikke aktiveres for Avamar MTree på en DD.

Kunder som bruker andre sikkerhetskopieringsprogrammer som ikke opprinnelig støtter oppbevaringslås for datadomener, kan også utvikle tilpassede skripter for å bruke Data Domain Retention Lock til å angi oppbevaringsperioder for filer manuelt. I dette scenariet må du sørge for at egendefinerte skript setter filens tid slik at de er låst opp før sikkerhetskopieringsprogrammet prøver å slette filen. Hvis du ikke gjør dette, kan det føre til at sikkerhetskopieringsprogrammet prøver å slette låste filer (som mislykkes). Filen blir liggende på DDR-en og bruker diskplass på ubestemt tid. Se administrasjonsveiledning for Data Domain.

Automatisk oppbevaringslås
For sikkerhetskopieringsprogrammer som ikke opprinnelig støtter Data Domain-oppbevaringslåsfunksjonen, har det alltid vært et problem for kundene å utnytte funksjonen. Sikkerhetskopiadministratoren må konfigurere skript for å angi oppbevaringslås på nylig inntatte filer for et MTree. Låsen må angis slik at den utløper kort tid før sikkerhetskopien skal utløpe (og slettes) av sikkerhetskopiadministratoren.

I motsetning til vanlig RL, setter automatisk oppbevaringslås en lås på hver eneste fil som er skrevet til MTree når funksjonen er aktivert. Dette faktum forhindrer at nye eller modifiserte filer endres eller fjernes i en gitt tidsperiode etter at den konfigurerte avkjølingsperioden er passert. Hvis MTree har filer som må endres på et senere tidspunkt (enten sikkerhetskopifiler eller sikkerhetskopiprogramrelaterte filer, for eksempel NetWorkers "volhdr" eller "_nsr_serial"), vil ARL forhindre at disse blir endret, noe som forårsaker alle slags mulige problemer.

Derfor støttes ikke ARL for VTL.

Av samme grunn støttes ikke ARL for NetWorker (bruk av ARL med NetWorker kan føre til utilsiktet datautilgjengelighet eller til og med tap av data).

Før DDOS 7.8 kan ikke automatisk oppbevaringslås brukes på DD Boost logiske lagringsenheter (LSU), og forsøk på å aktivere dette returnerer en feilmelding om at den ikke støttes. Fra 7.8 og nyere støttes ARL for DD Boost LSU-er.

ARL som brukes på mål-DD-er for Managed File Replication (MFR), bør ha lang nok "automatic-lock-delay" til å sikre at kloneoperasjoner er fullført for sikkerhetskopisettet før låsing angis på filene. Eksempel: En liten fil som er en del av et sikkerhetskopisett, replikeres raskt mens en større fil tar lengre tid, deretter er den første filen oppbevaringslåst når den større filen er ferdig med replikering og støter på en feil når NW prøver å flytte alle filene i sikkerhetskopisettet til den endelige arkiveringskatalogen.)

Nylige endringer i DDOS for fastcopy/filecopy resulterer i at "mtime" for kildefilen beholdes ved kopiering mellom plasseringer på samme DDR. Som ARL forsinkelse bestemmes ved å gjennomgå "mtime" av en fil (og kopi eller klone har "mtime" for den opprinnelige filen) avhengig av arbeidsflyten og tidspunktet det kan være tilfelle kopien / klone å bli automatisk låst ved opprettelse, hvis opprette kopien eller klonen tar lengre tid enn avkjøling perioden for den opprinnelige filen.

For gjeldende versjoner finnes det flere alternativer i mtree retention-lock CLI, som vist nedenfor. Denne funksjonen kan også konfigureres via brukergrensesnittet ved å velge "Automatisk" i stedet for "Manuell" i "Bruk" -alternativet:     

# mtree retention-lock set
{min-retention-period | max-retention-period |
automatic-retention-period | automatic-lock-delay} <period>
mtree <mtree-path>

Funksjonen automatisk oppbevaringslås låser en fil umiddelbart etter at en forhåndskonfigurert avkjølingsperiode utløper (automatisk-lås-forsinkelse). Når filen er skrevet til en oppbevaringslås aktivert MTree, og låsen er gyldig i "automatic-retention-period" fra det øyeblikket den ble angitt, oppstår låsen hvis verdien er innenfor verdiene "min-retention-period" og "max-retention-period" som er angitt for MTree.

Hvis du vil ha mer bruk og generelle detaljer om funksjonen, kan du se den tilhørende administrasjonsveiledningen for DDOS. Denne funksjonen er lite egnet i situasjoner der samme MTree brukes som mål for sikkerhetskopier som enten skal ha låsesett i ulike perioder, eller sikkerhetskopier som skal og sikkerhetskopier som ikke skal ha et låsesett til å begynne med.

Hva kan eller kan ikke gjøres mot en låst fil?

• Oppbevaringslåste filer er skrivebeskyttet og kan ikke endres eller slettes.
• Når en fils oppbevaringsperiode utløper, blir den "låst opp" - når den er i ulåst tilstand, kan filen fortsatt ikke endres, men den kan slettes. DDR sletter ikke automatisk en fil når oppbevaringsperioden utløper (påfølgende sletting må utføres fra et klientsystem eller sikkerhetskopiprogram).
• Når oppbevaringsperioden for en bestemt fil er angitt, kan den ikke reduseres (det vil si at filene atime ikke kan fremføres).
• Oppbevaringsperioder kan imidlertid økes (atime kan økes opp til maksimal oppbevaringsperiode for MTree).
• Eierskaps- og tillatelsesinnstillinger for en fil kan fortsatt endres mens filen er låst
• Det er bare mulig å gi nytt navn til eller slette en katalog i en oppbevaringslås MTree (RLGE/RLGD eller RLCE) hvis katalogen ikke inneholder noen filer. Hvis katalogen inneholder filer (selv om disse filene ikke er låst for oppbevaring), mislykkes navneendringen eller slettingen av katalogen
• Selv om det ikke endrer selve filinnholdet, er det ikke tillatt å endre navnefilene (gi nytt navn) som har et låsesett, men navneendringen er også tillatt når filens lås er utløpt. For filer som ikke lenger er låst, er sletting den eneste tillatte operasjonen. Dette endres i DDOS 7.7.4 når det er tillatt å endre navn på filen for filer som ikke lenger er låst.

Er det mulig å fjerne oppbevaringslåsen helt mot en fil eller et sett med filer?
Det er mulig å 'tilbakestille' (fjerne) oppbevaringslåsen mot filer i MTrees ved hjelp av styringsmodus - dette gjøres med følgende kommando:     

# mtree retention-lock revert [path]

Når oppbevaringslåsen mot en fil er fjernet, kan den endres eller slettes som normalt. Hvis denne kommandoen kjøres mot en katalog, blir oppbevaringslåsene fjernet for alle filer i denne katalogen og alle underkataloger.

Det er ikke mulig å tilbakestille en oppbevaringslås mot filer i MTrees ved hjelp av samsvarsmodus - hvis dette forsøkes, vises en tilsvarende feil:     

# mtree retention-lock revert /data/col1/rl_test_comp/testfile
This operation is not allowed. Mtree is in retention-lock compliance mode.

Hva skjer hvis en oppbevaringslåst fil forsøkes endret eller fjernet?
Ethvert forsøk på å endre eller slette en oppbevaringslåst fil fører til en tilsvarende permission denied feil:

# echo " test2" >> /data/col1/rl_test/testfile
bash: testfile: Permission denied
# rm testfile
rm: remove write-protected regular file `testfile'? y
rm: cannot remove `testfile': Permission denied

DDFS-logger indikerer at operasjonen mislyktes på grunn av at filen er låst:     

06/07 07:06:59.756 (tid 0x2b5a77605d50): Atime of retention-lock file /data/col1/rl_test/testfile is not expired.
06/07 07:07:42.504 (tid 0x2b5a79111390): Atime of retention-lock file /data/col1/rl_test/testfile is not expired.

Er det mulig å liste opp alle filer som er låst for oppbevaring?
Ja, dette kan utføres ved hjelp av mtree retention-lock report generate retention-details kommando:

mtree retention-lock report generate retention-details
mtrees {<mtree-list> | all}
[format {text | tsv | csv}]
[output-file <file-name>]
               Report detailed information of
               retention-lock files.

Hvis du for eksempel vil vise detaljer om alle låste filer i /data/col1/rl_test MTree Følgende vil bli utført:

sysadmin@ddxxxx# mtree retention-lock report generate retention-details mtrees /data/col1/jftest
Report generated on: Fri Jul  1 14:19:31 2016

Report for mtree: /data/col1/jftest
File Path        Mode        Size(Bytes)        Expiration Date
/data/col1/jftest/file1 governance 10521456 Sat Jul  2 22:35:48 2016
/data/col1/jftest/testdir/file2 governance 10521680 Sat Jul  2 22:35:42 2016
/data/col1/jftest/file3 governance 10521820 Sun Jul 10 22:36:09 2016
Total files: 3

Er det mulig å deaktivere oppbevaringslås helt for en MTree (etter at den er aktivert)?
Ja, for MTrees som bruker styringsmodus, utføres dette ved hjelp av mtree retention-lock disable kommando:

# mtree retention-lock disable mtree [mtree]

For example:
sysadmin@xxxx# mtree retention-lock disable mtree /data/col1/rl_test
Retention-lock feature is disabled (previously enabled) for mtree /data/col1/rl_test.

Once disabled, MTree list indicates that retention lock was used against the MTree but has since been disabled, that is: 

sysadmin@ddxxxx# mtree list
Name                                Pre-Comp (GiB)   Status    Tenant-Unit
---------------------------------   --------------   -------   -----------
...
/data/col1/rl_test                             0.0   RW/RLGD   -
...

sysadmin@ddxxxx# mtree retention-lock revert /data/col1/rl_test/testfile
**** Retention-lock feature is disabled (previously enabled) for mtree which contains the path /data/col1/rl_test/testfile.

• Oppbevaringslås kan ikke deaktiveres for et MTree i modus for overholdelse:     

sysadmin@ddxxxx# mtree retention-lock disable mtree /data/col1/rl_test_comp
**** Operation is not allowed because the system is a retention-lock compliance system

# mtree retention-lock revert /data/col1/myTree
The 'mtree retention-lock revert' command removes retention-lock on this path thereby making it unprotected.
	Are you sure:  (yes | no)  [no]:  yes
Ok, proceeding
Please enter sysadmin password to confirm 'mtree retention-lock revert':
**** The filesystem is not responding.

• Katalogreplikering – støttes bare for filer med styringsmodus – replikerer ikke minimum og maksimum oppbevaringsperioder til målsystemet.
• MTree-replikering – kan brukes til enten styrings- eller samsvarsmodusdata og replikerer minimum og maksimum oppbevaringsperioder til målsystemet.
• Replikering av innsamling – kan brukes for data i styrings- eller samsvarsmodus og replikerer minimum og maksimum oppbevaringsperioder til målsystemet.

# replication break mtree://[destination system]/data/col1/[mtree]

# mtree retention-lock enable mode compliance mtree [mtree]

# replication add source mtree://[source system]/data/col1/[mtree] destination mtree://[destination system/data/col1/[mtree]

# replication resync mtree://[destination system/data/col1/[mtree]

# user reset
# filesys destroy
# filesys archive unit del [archive unit name]

# mtree delete [mtree]
# mtree retention-lock reset [min-retention-period period | max-retention-period period] mtree [mtree]
# mtree retention-lock disable mtree [mtree]
# mtree retention-lock revert

# cloud unit del <cloud unit name>