# mtree retention-lock enable mode governance mtree [mtree]
(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]
Hur är det möjligt att avgöra vilka MTrees som har kvarhållningslås aktiverat?
MTrees med aktiverat kvarhållningslås indikeras i utdata från mtree list
till exempel:
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 ett MTree med styrning av låsning av förvaring av data konverteras till efterlevnad av låsning av förvaring?
Som anges i DDOS-administrationsguiden är detta inte möjligt.
Kan ett MTree med Retention Lock-efterlevnad aktiverat konverteras till Retention Lock Governance?
Som anges i DDOS-administrationsguiden är detta inte möjligt.
Hur ställs fillagrings- eller låsperioder in?
När ett kvarhållningslås har aktiverats mot ett MTree måste en lägsta och högsta kvarhållningsperiod ställas in. Dessa perioder anger den kortaste och längsta tid som en fil i MTree kan låsas. Till exempel:
# mtree retention-lock set min-retention-period [period] mtree [mtree]
# mtree retention-lock set max-retention-period [period] mtree [mtree]
Perioderna kan anges i olika enheter enligt följande:
Hur kan befintliga lagringsperioder visas?
Detta kan göras med följande två kommandon:
# mtree retention-lock show min-retention-period mtree [mtree] # mtree retention-lock show max-retention-period mtree [mtree]
Till exempel:
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.
Hur låses filer i ett MTree med kvarhållningslås aktiverat?
En fils tid kan ändras från en NFS- eller CIFS-klient med kommandot "touch":
# touch -a -t [expiry time] [file to be locked]
Om du till exempel vill ange en tid för /data/col1/rl_test/testfile till 07:05 den 8 juni:
# touch -a -t 06080705 /data/col1/rl_test/testfile
Perioden från aktuell tid till framtida tid måste ligga inom minimi- och maximilagringsperioderna för MTree. Annars genereras ett fel när filerna ändras samtidigt:
# touch -a -t 08080705 /data/col1/rl_test/testfile
touch: setting times of `/data/col1/rl_test/testfile': Permission denied
Ett motsvarande meddelande visas också i loggfilerna för 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-klienter (Windows) innehåller som standard inte ett pekkommando eller verktyg, men flera sådana verktyg är fritt tillgängliga för nedladdning från olika tredjepartswebbplatser.
Vilka säkerhetskopieringsprogram har stöd för automatisk kvarhållningslåsning av filer efter att de har skrivits till en DDR-enhet?
Data Domain Retention Lock är kompatibelt med NAS-baserade WORM-protokoll (Write-Once-Read-Many) som är branschstandard. Integreringen är kvalificerad med arkivprogram som Symantec Enterprise Vault, SourceOne, Cloud Tiering Appliance eller DiskXtender.
För Dell NetWorker stöds både styrnings- och efterlevnadslägen.
Från och med juni 2024 har de senaste Avamar-versionerna stöd för både efterlevnad och styrning av Data Domain-kvarhållningslås som en del av Avamar-funktionen "Oföränderliga säkerhetskopior". Mer information finns i artikeln nedan och i Avamar-dokumentationen:
Avamar och Data Domain: Aktivera Avamar oföränderliga säkerhetskopieringar och Data Domain-kompatibilitetsläge Kvarhållningslås
Det är viktigt att stegen för att aktivera Avamar-funktionen "Oföränderliga säkerhetskopior" följs strikt. Om du inte gör det kan det sluta med en Avamar MTree i DD som inte kan skrivas vidare till, eller som har driftsproblem som tvingar fram en långdragen återställning. Avamar fungerar inte med DD Automatic Retention Lock (ARL) och ARL får inte aktiveras för Avamar MTree på en DD.
Kunder som använder andra säkerhetskopieringsprogram som inte har inbyggt stöd för Data Domain-kvarhållningslås kan också utveckla anpassade skript för att använda Data Domain-kvarhållningslås för att manuellt ställa in kvarhållandeperioder för filer. I det här scenariot ska du se till att anpassade skript ställer in filens tid så att den låses upp innan säkerhetskopieringsprogrammet försöker ta bort filen. Om du inte gör detta kan det leda till att säkerhetskopieringsprogrammet försöker ta bort låsta filer (vilket misslyckas). Filen finns kvar på DDR-skivan och förbrukar diskutrymme på obestämd tid. Se Data Domain administrationsmanual.
Automatiskt kvarhållningslås
För säkerhetskopieringsprogram som inte har inbyggt stöd för Data Domain-kvarhållningslåsfunktionen har det alltid varit ett problem för kunder att utnyttja funktionen. Administratören för säkerhetskopiering måste konfigurera skript för att ställa in kvarhållningslås på nyligen inmatade filer för ett MTree. Låset måste ställas in så att det upphör att gälla strax innan säkerhetskopian ska upphöra att gälla (och tas bort) av säkerhetskopieringsadministratören.
ARL ställer in ett lås på varje fil som skrivs till MTree efter att funktionen har aktiverats, vilket förhindrar att filen ändras eller tas bort under en viss tidsperiod efter att den konfigurerade avkylningsperioden har passerat. Det innebär att ARL inte får aktiveras för arbetsbelastningar eller säkerhetskopieringsprogram som måste uppdatera vissa filer upprepade gånger över tid, till exempel i VTL-pooler (VTL-bandfiler skrivs upprepade gånger till) eller för säkerhetskopieringsprogram som behåller metadatainformation tillsammans med kundens säkerhetskopieringsfiler (till exempel NetWorker eller Avamar). Aktivera ARL i dessa instanser för att ha viktiga filer låsta under en viss tid, och när dessa filer måste skrivas till senare för andra säkerhetskopior misslyckas skrivningen, och det gör även efterföljande säkerhetskopieringar.
För att hjälpa säkerhetskopieringsadministratörer att minska arbetsbördan med att behålla kvarhållandelås för säkerhetskopieringsfiler och få DDOS att uppnå funktionsparitet med andra leverantörer, finns det sedan DDOS 6.2.0.20 en funktion som kan aktiveras från CLI för varje MTree med Retention Lock konfigurerat, för att ställa in ett lås på varje fil som matas in (under en viss period), efter att en viss förutbestämd tid har gått sedan filskrivningen till disken slutfördes. På så sätt behöver administratörer inte längre oroa sig för manuell (eller skriptad) inställning av kvarhållningslåset, och detta kan ske automatiskt utan samarbete med säkerhetskopieringsprogrammet.
Före DDOS 7.8 går det inte att använda Automatic Retention Lock på DD Boost logiska lagringsenheter (LSU) och försök att aktivera detta returnerar ett felmeddelande om att det inte stöds.
Från och med 7.8 stöds ARL för DD Boost LSU:er.
(ARL som används på mål-DD:er för hanterad filreplikering (MFR), t.ex. NW-klon, bör ha en tillräckligt lång "automatisk-låsfördröjning" för att säkerställa att kloningsåtgärderna slutförs för säkerhetskopieringsuppsättningen innan låsning anges för filerna. Exempel: En liten fil som är en del av en säkerhetskopia replikeras snabbt medan en större fil tar längre tid. Den första filen är kvarhållen när den större filen har replikerats och ett fel uppstår när NW försöker flytta alla filer i säkerhetskopian till den slutliga arkiveringskatalogen.)
Automatiskt kvarhållningslås stöds inte på Data Domain VTL.
På tillämpliga versioner finns det ytterligare alternativ i mtree retention-lock
CLI, som visas nedan. Den här funktionen kan även konfigureras via användargränssnittet genom att välja "Automatisk" istället för "Manuell" i alternativet "Använd":
# mtree retention-lock set
{min-retention-period | max-retention-period |
automatic-retention-period | automatic-lock-delay} <period>
mtree <mtree-path>
Funktionen för automatiskt kvarhållningslås låser en fil omedelbart efter att en förkonfigurerad avkylningsperiod har gått ut (automatisk-lås-fördröjning). När filen har skrivits till ett MTree aktiverat för kvarhållningslås och låset är giltigt för "automatic-retention-period" från det ögonblick det angavs, sker låsningen om värdet ligger inom värdena "min-retention-period" och "max-retention-period" som angetts för MTree.
Mer användning och allmän information om funktionen finns i motsvarande DDOS-administrationsmanual. Den här funktionen är inte lämplig för situationer där samma MTree används som mål för säkerhetskopior som antingen ska ha låsuppsättningar för olika perioder, eller säkerhetskopior som ska ha och säkerhetskopior som inte ska ha ett lås inställt till att börja med.
Vad kan och kan inte göras mot en låst fil?
Går det att helt ta bort kvarhållningslås mot en fil eller en uppsättning filer?
Det är möjligt att "återställa" (ta bort) kvarhållningslås mot filer i MTrees med hjälp av styrningsläge - detta görs med följande kommando:
# mtree retention-lock revert [path]
När kvarhållningslåset mot en fil har tagits bort kan det ändras eller tas bort som vanligt. Om det här kommandot körs mot en katalog tas kvarhållningslås bort för alla filer i katalogen och alla underkataloger.
Det går inte att återställa ett kvarhållningslås mot filer i MTrees med hjälp av kompatibilitetsläge – om du försöker göra detta visas ett motsvarande fel:
# mtree retention-lock revert /data/col1/rl_test_comp/testfile
This operation is not allowed. Mtree is in retention-lock compliance mode.
Vad händer om man försöker ändra eller ta bort en kvarhållningslåst fil?
Alla försök att ändra eller ta bort en kvarhållningslåst fil orsakar en motsvarande permission denied
fel:
# 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-loggar anger att åtgärden har misslyckats på grund av att filen är låst för kvarhållande:
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.
Är det möjligt att lista alla filer som är låsta?
Ja, detta kan utföras med hjälp av mtree retention-lock report generate retention-details
befallning:
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.
Om du till exempel vill visa information om alla låsta filer i /data/col1/rl_test MTree
Följande skulle utföras:
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
Är det möjligt att helt inaktivera kvarhållningslås för ett MTree (efter att det har aktiverats)?
Ja, för MTrees som använder styrningsläge utförs detta med hjälp av mtree retention-lock disable
befallning:
# 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]
Sådana system kan inte startas i enanvändarläge för återställning av teknisk support utan användning av en USB-enhet och fysisk åtkomst till 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 och senare versioner har dock en bestämmelse gjorts för att kunder ska kunna ta bort MTrees som är aktiverade för överensstämmelse med låsning av förvaring av data om:
# cloud unit del <cloud unit name>
# filesys enable