文書番号: 000079803

Data Domain: Vanliga frågor om Retention Lock

概要: Den här artikeln innehåller en översikt över RL-funktionen (Data Domain Retention Lock) och förklarar skillnaderna mellan konfiguration och användning av styrnings- och efterlevnadsläge. ...

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

文書の内容

現象

Den här artikeln ger en kortfattad översikt över RL-funktionen (Data Domain Retention Lock) och svar på vanliga frågor och svar.

原因

Den här artikeln ger en kortfattad översikt över RL-funktionen (Data Domain Retention Lock) och svar på vanliga frågor och svar.

解決方法

Vad är ett kvarhållningslås
Kvarhållningslås är en funktion som används på Data Domain Restorers (DDR) för att förhindra modifiering eller radering av vissa uppsättningar filer under en förutbestämd period. Det innebär att låsta filer för kvarhållning är skrivskyddade tills kvarhållningsperioden upphör att gälla.

Vilka är de olika versionerna av kvarhållningslås
Kvarhållningslås är tillgängligt för två olika funktioner:

Styrelseskick: Den mindre strikta av de två låsfunktionerna för förvaring (d.v.s. lås mot filer kan återställas vid behov).
Tillmötesgående: Den strängare av de två funktionerna som följer flera gemensamma regleringsstandarder. Det innebär att lås mot filer inte kan återställas. DDR måste konfigureras med en "säkerhetsansvarig" användare som måste autentisera vissa kommandon. Det finns olika begränsningar för andra funktioner för att förhindra att låsta data tas bort eller att lås återställs i förtid.

Obs!

Kompatibilitetsläget är endast tillgängligt i DDOS 5.3 (och senare).
Varje funktion i kvarhållningslås kräver en separat licensnyckel.
Låsfunktionen för förvaring aktiveras per MTree.
Ett enda system kan använda både styrnings- och efterlevnadsläge mot separata MTrees. Den måste dock ha separata styrnings- och efterlevnadslicenser installerade.
Aktivera inte någon form av DD-kvarhållningslås på MTrees som används för att lagra Avamar-data, såvida det inte krävs i Avamar-dokumentationen, som en del av att få den här funktionen att köras på Avamar. Om du aktiverar DD RL på ett sådant MTree utan att följa rätt Avamar-process kan det göra att MTree inte längre kan användas för säkerhetskopiering, vilket medför ett behov av lång återställning. Detta gäller särskilt om du aktiverar Automatic Retention Lock (ARL) för ett Avamar MTree.
Funktionen för låsning av förvaring av data kanske inte stöds mot MTrees som används för att lagra data med äldre versioner av Avamar eller skyddsprogramvarudata på en Integration Data Protection Appliance- eller PowerProtect Data Protection Series-enhet. Detta kan förhindra att Avamar eller skyddsprogramvaran i Integration Data Protection Appliance fungerar som förväntat och försätts i READONLY-läge.

Vilka dataåtkomstprotokoll stöds med låsning av förvaring?

NFS-, CIFS- och DD Boost-protokollen stöds fullt ut mot MTrees med styrning av kvarhållningslås eller efterlevnadsläge.
VTL-protokollet (Virtual Tape Library) stöds endast mot MTrees som använder styrningsläget för låsning av förvaring. Automatiskt kvarhållningslås stöds inte på Data Domain VTL. Se Data Domain Administration Guide för att ta reda på hur du låser upp kvarhållningslåsta band så att de kan skrivas till.

Överensstämmelseläget för kvarhållningslås uppfyller regelstandarder:
Listan över regelstandarder som överensstämmelseläget för kvarhållningslås uppfyller innehåller följande:

SEK 17a-4(f)
CFTC-regel 1.31b
FDA 21 CFR del 11
Sarbanes-Oxley-lagen
IRS 98025 och 97-22
ISO-standard 15489-1
MoREQ2010

Kontakta din kontrakterade supportleverantör om du vill ha fullständig information om certifieringen.

Hur aktiveras styrning av kvarhållningslås?

En styrningslicens för kvarhållningslås läggs till i DDR.
Styrningsläget för kvarhållningslås är aktiverat mot alla nödvändiga MTree:

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

Hur aktiveras efterlevnad av kvarhållningslås?

Det finns specifika anvisningar för vissa nyare Data Domain-modeller med iDRAC.
En efterlevnadslicens för kvarhållningslås läggs till i DDR.
En användare med rollen "säkerhet" bör skapas (förutsatt att en sådan användare inte finns):

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

Användaren med rollen "säkerhet" ska logga in på DDR och aktivera säkerhetsanvändarauktorisering:

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

Systemet ska konfigureras för efterlevnadsläge för låsning av förvaringslås När följande kommando körs startas systemet om automatiskt:

(ADMIN USER) # system retention-lock compliance configure

När systemet har startats om bör efterlevnadsläget för låsning av förvaring av data vara aktiverat i systemet:

(ADMIN USER) # system retention-lock compliance enable

Obs! För nyare DDOS-versioner måste den här uppgiften utföras med Data Domain-användargränssnittet. Efterlevnad av administrationskrav >

Kompatibilitetsläget för kvarhållningslås är aktiverat mot alla nödvändiga MTree:

(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 kvarhållningslås aktiverat anges i utdata för"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:

1 min
1 timme
1 dag
1 mån
1 år

Obs!

En minsta kvarhållningsperiod får inte vara mindre än 12 timmar.
En maximal kvarhållningsperiod får inte vara längre än 70 år.
Den minsta kvarhållningsperioden måste vara mindre än den maximala kvarhållningsperioden.
Kvarhållningsperioder för varje MTree ställs in på samma sätt oavsett vilken typ av kvarhållningslås som används.

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?

När kvarhållningslås är aktiverat mot ett MTree låses inte befintliga filer i MTree automatiskt (det vill säga att alla befintliga filer förblir läs- eller skrivbara).
När en ny fil skrivs till ett MTree med kvarhållningslås aktiverat låses inte filen automatiskt. Det innebär att den nya filen förblir läs- eller skrivbar.

Obs! Från och med DDOS 6.2.0.20 finns det en funktion i DDOS som kallas "automatiskt kvarhållningslås", som kan låsa alla skrivna filer automatiskt. Mer information finns i avsnittet "Automatiskt kvarhållningslås" längre ned i den här KB-artikeln.

Om du vill låsa en viss fil måste filens tid ändras så att den matchar det datum och den tid då filen ska låsas. Det är det datum och den tid fram till vilken filen ska förbli skrivskyddad. Tills tiden har ändrats på det här sättet kan filen inte låsas (och kan ändras eller tas bort).

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.

Obs! Filer kan inte kvarhållas låsta förrän de har skrivits till DDR. Det går inte att skapa en tom fil, kvarhålla, låsa filen och sedan skriva data till filen.

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.

För tillämpliga versioner finns det ytterligare alternativ i CLI för "mtree retention-lock", 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?

Kvarhållningslåsta filer är skrivskyddade och kan inte ändras eller tas bort.
När en fils kvarhållningsperiod går ut är den "olåst" - när den är i olåst tillstånd kan filen fortfarande inte ändras men den kan tas bort. DDR tar inte bort en fil automatiskt när kvarhållningsperioden går ut (efterföljande borttagning måste utföras från ett klientsystem eller säkerhetskopieringsprogram).
När lagringsperioden för en viss fil väl har ställts in kan den inte minskas (det vill säga att filerna inte kan vidarebefordras).
Kvarhållningsperioderna kan dock ökas (en tid kan ökas upp till den maximala kvarhållningsperioden för MTree).
Ägarskaps- och behörighetsinställningar för en fil kan fortsätta att ändras medan filen är låst
Det går bara att byta namn på eller ta bort en katalog i ett MTree som är aktiverat för låsning av förvaring om katalogen inte innehåller några filer. Om katalogen innehåller filer (även om dessa filer inte är låsta) går det inte att byta namn på katalogen eller ta bort den
Även om det inte ändrar själva filinnehållet är det inte tillåtet att ändra namnet (byt namn) på filer som har ett inställt lås, men namnbytet är inte heller tillåtet när filens lås har gått ut. För filer som inte längre är låsta är borttagning den enda åtgärd som tillåts. Detta ändras i DDOS 7.7.4 när, för filer som inte längre är låsta, ett nytt namn på filen tillåts.

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 ett motsvarande "behörighet nekad"-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, det kan utföras med kommandot "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.

Om du till exempel vill lista information om alla låsta filer i /data/col1/rl_test MTree skulle följande 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 kommandot "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   -
...

Obs! När kvarhållningslås har inaktiverats mot ett MTree:

Nya filer som skrivs till MTree kan inte kvarhållas.
Filer som redan är låsta förblir låsta under den tidigare definierade kvarhållningsperioden (det vill säga att alla lås inte återställs automatiskt när kvarhållningslås inaktiveras mot ett MTree).
Befintliga lås mot filer i ett MTree där kvarhållningslås är inaktiverat kan inte återställas. Alla nödvändiga omversioner måste göras innan kvarhållningslås inaktiveras:

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.

Kvarhållningslås kan inte inaktiveras för ett MTree med kompatibilitetsläge:

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 fortfarande användas mot MTrees som har kvarhållningslås aktiverat?

Ja, kvarhållningslåsta MTrees eller filer kan replikeras med hjälp av olika replikeringstopologier:

Katalogreplikering – stöds endast för filer som använder styrningsläge – replikerar inte minimi- och maximikvarhållningsperioder till målsystemet.
MTree-replikering – kan användas för antingen styrnings- eller efterlevnadslägesdata och replikerar minimi- och maximikvarhållningsperioder till målsystemet.
Samlingsreplikering – kan användas för antingen styrnings- eller efterlevnadslägesdata och replikerar minimi- och maximikvarhållningsperioder till målsystemet.

Obs! För att kvarhållningslås ska bevaras på målsystem:

Både käll- och målsystemen måste ha motsvarande licenser för låsning av förvaring av data.
MTree-replikeringskontexter måste ha "Replication propagate-retention-lock" inställt på Enabled.
För filer som replikeras av katalogreplikering måste motsvarande MTrees lägsta och högsta kvarhållningsperioder anges manuellt i målsystemet.

Finns det några andra begränsningar vid replikering av låsta filer för kvarhållning?

Ja, omsynkronisering av replikeringskontexter (det vill säga försöker återupprätta en tidigare konfigurerad men bruten kontext) där kvarhållningslåsta data används för kan misslyckas.

Obs!

Om MTree-replikering används och målets MTree innehåller kvarhållningslåsta filer som inte finns på källan, misslyckas en omsynkronisering.
Om katalogreplikering används för att och målet har ett kvarhållningslås som är aktiverat men källan inte gör det, misslyckas en omsynkronisering.

Obs! När du använder MTree-replikering lyckas en omsynkronisering i följande scenarier, om målets MTree inte innehåller kvarhållningslåsta filer som inte finns på käll-DDR:

Käll-MTree har inte kvarhållningslås aktiverat, men målet har det.
Målets MTree har inte kvarhållningslås aktiverat, men källan har det.

Det går inte heller att aktivera kompatibilitetsläge för kvarhållningslås på ett MTree som redan är medlem i en MTree-replikeringskontext. I det här scenariot:

MTree-replikeringskontexten bör brytas på både käll- och målsystem:

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

En ny MTree-replikeringskontext bör skapas på både käll- och målsystem:

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

Efterlevnadsläget för kvarhållningslås ska vara aktiverat på källsystemet:

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

Den nyligen skapade replikeringskontexten bör synkroniseras om i källsystemet:

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

Kan kvarhållningslåsta filer kopieras snabbt?

Ja, filer som är kvarhållningslåsta kan kopieras snabbt som vanligt. Om målets MTree som innehåller den snabba kopian är aktiverat för kvarhållningslås bevaras filens kvarhållningslås mot snabbkopian. Om mål-MTree inte är aktiverat för kvarhållningslås är snabbkopian inte låst.

Finns det några andra begränsningar i systemfunktionerna när du använder kvarhållningslås

Följande kommandon är inte tillåtna på system som använder kompatibilitetsläge för låsning av förvaringslås

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

Följande kommandon tillåts inte mot MTrees med kompatibilitetsläge för låsning av förvaringslås i följande lägen:

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

DD kör DDOS 7.3 eller senare.
Den RLCE MTree som ska tas bort är tom (har noll filer och kataloger).
Administratören godkänns som säkerhetsansvarig.

I system som är konfigurerade med långsiktig lagring (Cloud Tier) kan liknande destruktiva kommandon också vara otillåtna, till exempel:

# cloud unit del <cloud unit name>

Obs! MTrees som använder styrningsläge för låsning av förvaring av data (eller där det här läget en gång var aktiverat) kan bara tas bort när MTree inte innehåller några filer – om det finns några filer kvar i MTree returneras ett fel.

Är systemklockan viktig på system med låsning av förvaring?

Ja, system som är kompatibla med kvarhållningslås aktiverar en intern "säkerhetsklocka" för att förhindra skadlig manipulering av systemklockan (vilket kan tillåta att kvarhållandelåsta filer raderas tidigt). Tiderna för säkerhets- och systemklockorna jämförs regelbundet, och om det finns en ackumulerad 2-veckors skevhet mellan de två under ett enda kalenderår inaktiveras Data Domain File System (DDFS) automatiskt för att förhindra åtkomst till data på DDR. Detta kan också hända om systemklockan plötsligt ändras och tiden ändras med mer än 2 veckor.

I det här scenariot kan DDFS återaktiveras genom att:

Logga in på DDR
Kontrollera att systemklockan är korrekt inställd.
Aktivera filsystemet:
```
# filesys enable
```
När du uppmanas till det anger du information om en användare med säkerhetsrollen så att säkerhetsklockan kan återställas och aktiverar DDFS.

Kan systemklockan synkroniseras med Active Directory på system som är kompatibla med låsning av förvaringslås i systemet?
Nej, när överensstämmelse med låsning av förvaring av data är aktiverat synkroniserar CIFS-servrar inte längre systemtiden med Active Directory. Om det finns en tidsskillnad på mer än fem minuter mellan systemet och Active Directory visar CIFS-servern ett felmeddelande när en Active Directory-användare försöker logga in, eller systemet försöker ansluta till en Active Directory-domän. Konfigurera Active Directory-tid med NTP för att undvika det här felet.

Detta till skillnad från system där överensstämmelse med låsning av förvaring av data inte är aktiverat men Active Directory används. I det här fallet rekommenderar vi inte att du aktiverar NTP eftersom det kan finnas tidsinställningskonflikter mellan Active Directory och NTP.

Vilka åtgärder kan vidtas om en DDR som använder kvarhållningslåsta filer blir fullbelagd?

Förutsatt att det inte finns något "rengöringsbart" utrymme på DDR (rensning körs men systemet förblir fyllt till sin kapacitet) bör dess innehåll granskas för att avgöra om:

Det finns filer som inte är låsta och som kan tas bort.
Det finns alla filer som är låsta med styrningsläge som kan få sina lås återställda och borttagna.

När detta är gjort bör rensningen köras igen för att fysiskt frigöra utrymme på systemet. Om inga fysiska data kan tas bort från systemet bör ytterligare fysisk lagring läggas till i DDR och filsystemet utökas (förutsatt att expansion stöds av aktuell DDR eller konfiguration).

Om de enda filerna i systemet är låsta i kompatibilitetsläge går det inte att återställa låsen och ta bort filerna. Som ett resultat kan utrymme inte frigöras om inte:

Kvarhållningsperioden har nåtts för vissa eller alla filer. Efter denna punkt kan de tas bort och köras rent (enligt beskrivningen ovan).
Systemet installeras om från en USB-enhet (vilket gör att alla data på DDR-enheten går förlorade).
Mer fysiskt lagringsutrymme läggs till i systemet (enligt beskrivningen ovan).

Obs! Det är fullt möjligt att helt fylla en DDR med filer som är låsta med efterlevnadsläge. I det här scenariot finns det inget som en administratör eller teknisk support kan göra för att frigöra utrymme (det vill säga att det inte finns någon lågnivåfunktion för att ta bort/återställa lås för kompatibilitetsläge och ta bort motsvarande filer tidigt).

文書のプロパティ

影響を受ける製品

Data Domain, Data Domain Retention Lock

製品

Data Domain

最後に公開された日付

18 7月 2024

バージョン

文書の種類

Solution

トップに戻る

ようこそ

Dellへようこそ

Data Domain: Vanliga frågor om Retention Lock

概要: Den här artikeln innehåller en översikt över RL-funktionen (Data Domain Retention Lock) och förklarar skillnaderna mellan konfiguration och användning av styrnings- och efterlevnadsläge. ... 表示を増やす 表示を減らす

文書の内容

現象

原因

解決方法

文書のプロパティ

影響を受ける製品

製品

最後に公開された日付

バージョン

文書の種類

概要: Den här artikeln innehåller en översikt över RL-funktionen (Data Domain Retention Lock) och förklarar skillnaderna mellan konfiguration och användning av styrnings- och efterlevnadsläge. ...