文書番号: 000079803

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

概要: Denne artikkelen inneholder en oversikt over Data Domain Retention Lock-funksjonalitet (RL) og forklarer forskjellene mellom konfigurasjon og bruk av styrings- og samsvarsmodus.

この記事は自動翻訳されたものである可能性があります。品質に関するフィードバックがある場合は、このページの下部にあるフォームを使用してお知らせください。

文書の内容

現象

Denne artikkelen gir en kortfattet oversikt over Data Domain Retention Lock-funksjonalitet (RL) og svar på relaterte vanlige spørsmål.

原因

Denne artikkelen gir en kortfattet oversikt over Data Domain Retention Lock-funksjonalitet (RL) og svar på relaterte vanlige spørsmål.

解決方法

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.

Merk:

Modus for overholdelse er bare tilgjengelig i DDOS 5.3 (og nyere).
Hver funksjon av oppbevaringslåsen krever en egen lisensnøkkel.
Oppbevaringslås funksjonalitet er aktivert per MTree-basis.
Ett enkelt system kan bruke både styrings- og samsvarsmodus mot separate MTrees. Det må imidlertid ha separate styrings- og samsvarslisenser installert.
Ikke aktiver noen form for DD-oppbevaringslås på MTrees som brukes til å lagre Avamar-data, med mindre det kreves i Avamar-dokumentasjonen, som en del av å få denne funksjonen til å kjøre på Avamar. Hvis du aktiverer DD RL på en slik MTree uten å følge riktig Avamar-prosess, kan det gjøre MTree ubrukelig for sikkerhetskopiering og medføre behov for langvarig gjenoppretting. Dette gjelder spesielt hvis du aktiverer automatisk oppbevaringslås (ARL) for en Avamar MTree.
Det kan hende at oppbevaringslåsfunksjonalitet ikke støttes mot MTrees som brukes til å lagre data ved hjelp av eldre versjoner av Avamar- eller beskyttelsesprogramvaredata på et Integrated Data Protection Appliance- eller PowerProtect Data Protection Series-apparat. Dette kan forhindre at Avamar- eller beskyttelsesprogramvaren i Integrated Data Protection Appliance fungerer som forventet og går til READONLY-tilstand.

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

Merk: For nyere DDOS-versjoner må denne oppgaven utføres med Data Domain-brukergrensesnittet. Administrasjonssamsvar >

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 oppbevaringslås aktivert er angitt i utdataene fra 'mtree list', for 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

Merk:

En minimum oppbevaringsperiode kan ikke være mindre enn 12 timer.
En maksimal oppbevaringsperiode kan ikke være lengre enn 70 år.
Minste oppbevaringsperiode må være mindre enn den maksimale oppbevaringsperioden.
Oppbevaringsperioder for hver MTree er satt på samme måte uavhengig av smaken av oppbevaringslås som brukes.

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.

Merk: Fra og med DDOS 6.2.0.20 er det en funksjon i DDOS som kalles "automatisk oppbevaringslås", som kan sette en lås på alle skrevne filer automatisk. Se delen "Automatisk oppbevaringslås" lenger ned i denne KB-artikkelen for å finne ut mer.

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]

Hvis du for eksempel vil angi /data/col1/rl_test/testfile til 07:05 den 8. juni:

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

Merk: Filer kan ikke oppbevaringslås før de er skrevet til DDR. Det er ikke mulig å opprette en tom fil, beholde lås den filen, og deretter skrive data til filen.

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.

ARL setter en lås på hver eneste fil som skrives til MTree etter at funksjonen er aktivert, og forhindrer at filen endres eller fjernes i en gitt tidsperiode etter at den konfigurerte avkjølingsperioden er passert. Det betyr at ARL ikke må aktiveres for arbeidsbelastninger eller sikkerhetskopieringsprogrammer som må oppdatere noen filer gjentatte ganger over tid, for eksempel på VTL-utvalg (VTL-båndfiler skrives gjentatte ganger til), eller for sikkerhetskopieringsprogrammer som beholder metadatainformasjon sammen med selve kundesikkerhetskopifilene (for eksempel NetWorker eller Avamar). Aktivering av ARL i disse tilfellene for å ha viktige filer låst en stund, og når disse filene må skrives til senere for andre sikkerhetskopier, mislykkes skrivingen, og det samme vil eventuelle påfølgende sikkerhetskopier.

For å hjelpe administratorer med sikkerhetskopiering med å redusere belastningen ved å beholde sikkerhetskopieringsfiler og få DDOS opp på funksjonsparitet med andre leverandører, siden DDOS 6.2.0.20 er det en funksjon som kan aktiveres fra CLI for hver MTree med oppbevaringslås konfigurert, for å sette en lås på hver inntatt fil (for en gitt periode), Etter at det har gått litt forhåndsbestemt tid siden filen skriv til disk ble fullført. På denne måten trenger ikke administratorer lenger å bekymre seg for manuelt (eller skriptet) å angi oppbevaringslåsen, og dette kan skje automatisk uten samarbeid med sikkerhetskopieringsprogrammet.
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 brukes på mål-DD-er for Managed File Replication (MFR), som NW-klon, bør ha en lang nok "automatic-lock-delay" til å sikre at kloneoperasjoner er fullført for sikkerhetskopisettet før lås er angitt 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.)

Automatisk oppbevaringslås støttes ikke på Data Domain VTL.

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 MTree-aktivert oppbevaringslås 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 forårsaker en tilsvarende feilmelding om nektet tillatelse:

# 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 kommandoen 'mtree retention-lock report generate retention-details':

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, vil følgende 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 kommandoen 'mtree retention-lock disable':

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

Merk: Når oppbevaringslåsen er deaktivert mot et MTree:

Nye filer som er skrevet til MTree, kan ikke oppbevaringslåses.
Filer som allerede er låst, forblir låst i den tidligere definerte oppbevaringsperioden (det vil si at alle låser ikke automatisk tilbakestilles når oppbevaringslås deaktiveres mot et MTree).
Eksisterende låser mot filer i et MTree der oppbevaringslås er deaktivert, kan ikke tilbakestilles. Alle nødvendige tilbakevendinger må gjøres før festelåsen deaktiveres:

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

Kan replikering fortsatt brukes mot MTrees som har festelås aktivert?

Ja, oppbevaringslåste MTrees eller filer kan replikeres ved hjelp av ulike replikeringstopologier:

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.

Merk: For oppbevaringslåser som skal bevares på destinasjonssystemer:

Både kilde- og målsystemene må ha tilsvarende lisenser for oppbevaringslås som er installert.
MTree-replikeringskontekster må ha 'Replication propagate-retention-lock' satt til Aktivert.
For filer som replikeres ved hjelp av katalogreplikering, må de tilsvarende minimums- og maksimumsoppbevaringsperiodene for MTrees angis manuelt på målsystemet.

Er det noen andre begrensninger ved replikering av oppbevaringslåste filer?

Ja, resynkronisering av replikeringskontekster (som prøver å gjenopprette en tidligere konfigurert, men ødelagt kontekst) der oppbevaring av låste data er vant til, kan mislykkes.

Merk:

Hvis MTree-replikering brukes, og mål-MTree inneholder oppbevaringslåste filer som ikke finnes på kilden, mislykkes en resynkronisering.
Hvis katalogreplikering er vant til og målet har en oppbevaringslås som er aktivert, men kilden ikke har det, mislykkes en ny synkronisering.

Merk: Når du bruker MTree-replikering, lykkes en resynkronisering i følgende scenarier hvis mål-MTree ikke inneholder oppbevaringslåste filer som ikke finnes i kilde-DDRen:

Kilden MTree har ikke oppbevaringslås aktivert, men målet gjør det.
Mål-MTree har ikke oppbevaringslås aktivert, men det har kilden.

Det er heller ikke mulig å aktivere modus for overholdelse av oppbevaringslås på en MTree-replikeringskontekst som allerede er medlem av en MTree-replikeringskontekst. I dette scenariet:

MTree-replikeringskonteksten bør brytes på både kilde- og målsystemer:

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

En ny MTree-replikeringskontekst bør opprettes på både kilde- og målsystemer:

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

Modus for overholdelse av oppbevaringslås bør være aktivert på kildesystemet:

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

Den nylig opprettede replikeringskonteksten bør synkroniseres på nytt på kildesystemet:

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

Kan oppbevaringslåste filer kopieres raskt?

Ja, filer som er låst kan raskt kopieres som normalt. Hvis mål-MTree som inneholder hurtigkopien, er aktivert for oppbevaringslås beholdes oppbevaringslåsen for filen mot hurtigkopien. Hvis mål-MTree ikke er oppbevaringslås aktivert, er ikke hurtigkopien oppbevaringslåst.

Er det andre begrensninger i systemfunksjonaliteten ved bruk av oppbevaringslås?

Følgende kommandoer er ikke tillatt på systemer som bruker modus for overholdelse av oppbevaringslås:

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

Slike systemer kan ikke startes opp til enkeltbrukermodus for gjenoppretting ved hjelp av teknisk støtte uten bruk av en USB-stasjon og fysisk tilgang til systemet.

Følgende kommandoer er ikke tillatt mot MTrees ved bruk av samsvarsmodus for oppbevaringslås:

# 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

I DDOS 7.3 og nyere versjoner er det imidlertid lagt til rette for at kunder skal kunne slette Retention Lock Compliance-aktiverte MTrees hvis:

DD kjører DDOS 7.3 eller nyere.
RLCE MTree som skal slettes er tom (har null filer og kataloger).
Administratoren består godkjenning av sikkerhetsansvarlig.

I systemer som er konfigurert med langsiktig oppbevaring (skynivå), kan lignende destruktive kommandoer også være tillatt, for eksempel:

# cloud unit del <cloud unit name>

Merk: MTrees som bruker styringsmodus for oppbevaringslås (eller der denne modusen en gang var aktivert), kan bare slettes når MTree ikke inneholder noen filer - hvis det er noen filer igjen i MTree, returneres en feil.

Er systemklokken viktig på systemer som er aktivert for oppbevaringslås?

Ja, systemer som er aktivert for overholdelse av oppbevaringslåser, aktiverer en intern "sikkerhetsklokke" for å forhindre ondsinnet tukling med systemklokken (som kan føre til at oppbevaringslåste filer slettes tidlig). Klokkeslettene for sikkerhet og systemklokker sammenlignes regelmessig, og hvis det er en akkumulert 2-ukers skjevhet mellom de to i ett enkelt kalenderår, deaktiveres Data Domain File System (DDFS) automatisk for å hindre tilgang til data på DDR. Dette kan også skje hvis systemklokken plutselig endres og tiden endres med mer enn 2 uker.

I dette scenariet kan DDFS aktiveres på nytt ved å:

Logge på DDR
Kontroller at systemklokken er riktig innstilt.
Aktivere filsystemet:
```
# filesys enable
```
Når du blir bedt om det, angir du detaljer for en bruker med sikkerhetsrollen for å tillate at sikkerhetsklokken tilbakestilles, og aktiverer DDFS.

Kan systemklokken synkroniseres med Active Directory på systemer som er aktivert for samsvar med oppbevaringslåsen?
Nei, når overholdelse av lagringslås er aktivert, synkroniserer ikke CIFS-servere lenger systemtiden med Active Directory. Hvis det er en tidsforskjell på mer enn fem minutter mellom systemet og Active Directory, viser CIFS-serveren en feilmelding når en Active Directory-bruker forsøker å logge på, eller systemet prøver å koble til et Active Directory-domene. Konfigurer Active Directory-tid med NTP for å unngå denne feilen.

Dette i motsetning til systemer der overholdelse av oppbevaringslås ikke er aktivert, men Active Directory er i bruk. I denne situasjonen anbefales det ikke å aktivere NTP, da det kan være tidsinnstillingskonflikter mellom Active Directory og NTP.

Hva kan gjøres hvis en DDR som bruker oppbevaringslåste filer, fylles opp til kapasiteten?

Forutsatt at det ikke er noen "rengjørbar" plass på DDR (ren kjøres, men systemet forblir fylt til kapasitet), bør innholdet gjennomgås for å avgjøre om:

Det er noen filer som ikke er oppbevaring låst som kan fjernes.
Det er noen filer som er låst ved hjelp av styringsmodus som kan få låsene sine tilbakestilt og fjernet.

Når dette er gjort, bør rengjøre kjøres igjen til fysisk ledig plass på systemet. Alternativt, hvis ingen fysiske data kan slettes fra systemet, bør ytterligere fysisk lagring legges til DDR og filsystemet utvides (forutsatt at utvidelsen støttes av gjeldende DDR eller konfigurasjon).

Hvis de eneste filene på systemet er låst i samsvarsmodus, er det ikke mulig å tilbakestille låsene og fjerne disse filene. Som et resultat er plass ikke i stand til å frigjøres, med mindre:

Oppbevaringsperioden er nådd for noen eller alle filene. Etter dette punktet kan de slettes og rengjøres (som beskrevet ovenfor).
Systemet installeres på nytt fra en USB-stasjon (noe som fører til tap av alle dataene på DDR).
Mer fysisk lagring legges til systemet (som beskrevet ovenfor).

Merk: Det er fullt mulig å fylle en DDR fullstendig med filer låst ved hjelp av samsvarsmodus. I dette scenariet er det ingenting en administrator eller teknisk støtte kan gjøre for å frigjøre plass (det vil si at det ikke er noen lavnivåfunksjonalitet for å fjerne/tilbakestille låser i samsvarsmodus og slette tilsvarende filer tidlig).

文書のプロパティ

影響を受ける製品

Data Domain, Data Domain Retention Lock

製品

Data Domain

最後に公開された日付

18 7月 2024

バージョン

文書の種類

Solution

トップに戻る

ようこそ

Dellへようこそ

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

概要: Denne artikkelen inneholder en oversikt over Data Domain Retention Lock-funksjonalitet (RL) og forklarer forskjellene mellom konfigurasjon og bruk av styrings- og samsvarsmodus.

文書の内容

現象

原因

解決方法

文書のプロパティ

影響を受ける製品

製品

最後に公開された日付

バージョン

文書の種類