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:
Hvilke datatilgangsprotokoller støttes med oppbevaringslås?
Modus for overholdelse av oppbevaringslås oppfyller forskriftsmessige standarder:
Listen over forskriftsmessige standarder som samsvarsmodus for oppbevaringslås oppfyller inkluderer følgende:
Hvis du vil ha fullstendig informasjon om sertifisering, kan du kontakte den avtalte støtteleverandøren.
Hvordan aktiveres styring av oppbevaringslås?
# mtree retention-lock enable mode governance mtree [mtree]
Hvordan aktiveres overholdelse av oppbevaringslås?
(ADMIN USER) # user add [username] role security
(SECURITY USER): # authorization policy set security-officer enabled
(ADMIN USER) # system retention-lock compliance configure
(ADMIN USER) # system retention-lock compliance enable
(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 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:
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?
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.
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?
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.
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
# replication break mtree://[destination system]/data/col1/[mtree]
# replication add source mtree://[source system]/data/col1/[mtree] destination mtree://[destination system/data/col1/[mtree]
# mtree retention-lock enable mode compliance mtree [mtree]
# replication resync mtree://[destination system/data/col1/[mtree]
# 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.
# 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 revertI DDOS 7.3 og nyere versjoner er det imidlertid lagt til rette for at kunder skal kunne slette Retention Lock Compliance-aktiverte MTrees hvis:
# cloud unit del <cloud unit name>
# filesys enable