文書番号: 000079803

Data Domain: Säilytyslukon usein kysytyt kysymykset

概要: Tämä artikkeli sisältää yleiskatsauksen Data Domain Retention Lock (RL) -toiminnoista ja selittää hallinnan ja vaatimustenmukaisuustilan määritysten ja käytön erot.

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

文書の内容

現象

Tämä artikkeli sisältää tiiviin yleiskatsauksen Data Domain Retention Lock (RL) -toiminnoista ja vastauksia usein kysyttyihin kysymyksiin (FAQ).

原因

Tämä artikkeli sisältää tiiviin yleiskatsauksen Data Domain Retention Lock (RL) -toiminnoista ja vastauksia usein kysyttyihin kysymyksiin (FAQ).

解決方法

Mikä on säilytyslukko?
Säilytyslukitus on ominaisuus, jota käytetään Data Domain Restorersissa (DDR) estämään tiettyjen tiedostojoukkojen muokkaaminen tai poistaminen ennalta määrätyksi ajaksi. Toisin sanoen säilytyslukitut tiedostot ovat vain luku -tilassa, kunnes niiden säilytysaika päättyy.

Mitkä ovat säilytyslukon eri versiot?
Säilytyslukko on saatavana kahdelle eri toiminnolle:

Hallintotapa: Kahdesta säilytyslukitustoiminnosta vähemmän tiukka (eli tiedostolukitukset voidaan palauttaa tarvittaessa).
Noudattaminen: Tiukempi kahdesta tehtävästä, jotka noudattavat useita yhteisiä sääntelystandardeja. Toisin sanoen tiedostolukkoja ei voi palauttaa. DDR:ään on määritettävä Security Officer -käyttäjä, jonka on todennettava tietyt komennot. Muilla toiminnoilla on erilaisia rajoituksia, jotka estävät lukittujen tietojen poistamisen tai lukkojen palauttamisen etuajassa.

Huomautus:

Yhteensopivuustila on käytettävissä vain DDOS 5.3:ssa (ja uudemmissa).
Jokainen säilytyslukon toiminto vaatii erillisen lisenssiavaimen.
Säilytyksen lukitustoiminto on käytössä MTree-kohtaisesti.
Yksittäinen järjestelmä voi käyttää sekä hallinto- että vaatimustenmukaisuustilaa erillisiä MTree-järjestelmiä vastaan. Sillä on kuitenkin oltava erilliset hallinta- ja vaatimustenmukaisuuslisenssit asennettuna.
Älä ota käyttöön minkäänlaista DD-säilytyslukitusta MTreesissä, joita käytetään Avamar-tietojen tallentamiseen, ellei Avamarin dokumentaatiossa niin vaadita osana tämän toiminnon käynnistämistä Avamarissa. DD RL:n ottaminen käyttöön MTreessä ilman oikeanpuoleista Avamar-prosessia saattaa muuttaa MTreen varmuuskopiointikelvottomaksi ja vaatia pitkää palautusta. Tämä pätee erityisesti, jos automaattinen säilytyslukitus (ARL) on käytössä Avamar MTree -mallissa.
Säilytyksen lukitustoimintoa ei ehkä tueta MTreesissä, jota käytetään tietojen tallentamiseen Integration Data Protection Appliance- tai PowerProtect Data Protection Series -laitteen vanhemmilla versioilla. Tämä voi estää Avamaria tai Integration Data Protection Appliancen sisällä olevaa suojausohjelmistoa toimimasta odotetusti ja siirtymästä vain luku -tilaan.

Mitä tietojen käyttöprotokollia säilytyslukitus tukee?

NFS-, CIFS- ja DD Boost -protokollia tuetaan täysin MTreesiä vastaan säilytyksen lukituksen hallintaa tai vaatimustenmukaisuustilaa käytettäessä.
VTL (Virtual Tape Library) -protokollaa tuetaan vain MTreesiä vastaan, joka käyttää säilytyksen lukituksen hallintatilaa. Data Domain VTL ei tue automaattista säilytyksen lukitusta. Katso Data Domain Administration Guide -oppaasta, miten säilytyslukittujen nauhojen lukitus avataan siten, että niille voi kirjoittaa.

Säilytyslukituksen vaatimustenmukaisuustila täyttää säädöstenmukaisuusvaatimukset:
Luettelo säädösstandardeista, jotka säilytyksen lukituksen yhteensopivuustila täyttää, sisältää seuraavat:

SECC 17a-4(f)
CFTC-sääntö 1.31b
FDA 21 CFR, osa 11
Sarbanes-Oxley-laki
IRS 98025 ja 97-22
ISO-standardi 15489-1
MoREQ2010

Lisätietoja sertifioinnista saat sopimuksen tehneeltä tukipalvelujen tarjoajalta.

Miten säilytyslukituksen hallinta otetaan käyttöön?

DDR:ään lisätään säilytyslukituksen hallintalisenssi.
Säilytyksen lukituksen hallintatila on käytössä kaikissa pakollisissa MTree-tilanteissa:

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

Miten säilytyslukituksen noudattaminen otetaan käyttöön?

Joillekin uudemmille Data Domain -malleille, joissa on iDRAC, on omat ohjeet.
Säilytyslukon vaatimustenmukaisuuslisenssi on lisätty DDR:ään.
Olisi luotava käyttäjä, jolla on "turvallisuusrooli" (olettaen, että tällaista käyttäjää ei ole olemassa):

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

Käyttäjän, jonka rooli on "security", tulee kirjautua DDR:ään ja ottaa käyttöön suojauskäyttäjän valtuutus:

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

Järjestelmä on määritettävä säilytyksen lukituksen vaatimustenmukaisuustilaan. Kun seuraava komento on suoritettu, järjestelmä käynnistyy uudelleen automaattisesti:

(ADMIN USER) # system retention-lock compliance configure

Kun järjestelmä on käynnistynyt uudelleen, säilytyksen lukituksen vaatimustenmukaisuustilan on oltava käytössä järjestelmässä:

(ADMIN USER) # system retention-lock compliance enable

Huomautus: Uudemmissa DDOS-versioissa tämä tehtävä on tehtävä Data Domain -käyttöliittymässä. Hallinnon > vaatimustenmukaisuus

Säilytyksen lukituksen vaatimustenmukaisuustila on käytössä kaikissa pakollisissa MTree-tilanteissa:

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

Miten on mahdollista määrittää, missä MTreeissä säilytyslukitus on käytössä?
MTreet, joissa säilytyslukitus on käytössä , ilmoitetaan 'mtree-luettelon' tulosteessa, esimerkiksi:

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

Voidaanko MTree, jossa Retention Lock Governance on käytössä, muuntaa Retention Lock -yhteensopivaksi?
Kuten DDOS:n hallintaoppaassa todetaan, tämä ei ole mahdollista.

Voidaanko MTree, jossa Retention Lock Compliance on käytössä, muuntaa säilytyslukituksen hallinnaksi?
Kuten DDOS:n hallintaoppaassa todetaan, tämä ei ole mahdollista.

Miten tiedostojen säilytys- tai lukitusajat asetetaan?
Kun säilytyslukko on otettu käyttöön MTree:tä vastaan, on asetettava vähimmäis- ja enimmäissäilytysaika. Nämä ajanjaksot määrittävät vähimmäis- ja enimmäisajan, jonka MTree-tiedostossa oleva tiedosto voidaan lukita. Esimerkki:

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

Jaksot voidaan antaa eri yksiköissä seuraavasti:

1 minuutti
1 tunti
1 päivä
1 kk
1 vuosi

Huomautus:

Vähimmäissäilytysaika ei saa olla alle 12 tuntia.
Enimmäissäilytysaika voi olla enintään 70 vuotta.
Vähimmäissäilytysajan on oltava lyhyempi kuin enimmäissäilytysaika.
Kunkin MTree:n säilytysajat asetetaan samalla tavalla riippumatta käytetystä retentiolukon mausta.

Miten olemassa olevat säilytysajat voidaan näyttää?
Tämä voidaan tehdä seuraavilla kahdella komennolla:

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

Esimerkki:

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.

Miten MTree-tiedostot, joissa säilytyslukitus on käytössä, lukitaan?

Kun säilytyslukitus on käytössä MTree:tä vastaan, MTree:n olemassa olevia tiedostoja ei lukita automaattisesti (eli kaikki olemassa olevat tiedostot pysyvät luku- tai kirjoitusaktiivisina).
Kun MTreelle kirjoitetaan uusi tiedosto säilytyslukitus käytössä, tiedoston säilytys ei ole automaattisesti lukittu. Toisin sanoen uusi tiedosto pysyy luettuna tai kirjoitettuna.

Huomautus: DDOS 6.2.0.20 -versiosta alkaen DDOS:ssa on ominaisuus nimeltä "automaattinen säilytyksen lukitus", joka saattaa lukita kaikki kirjoitetut tiedostot automaattisesti. Katso lisätietoja tämän tietämyskannan artikkelin jäljempänä olevasta Automaattinen säilytyksen lukitus -osasta.

Jos haluat lukita tietyn tiedoston, tiedoston atime-aikaa on muutettava vastaamaan päivämäärää ja aikaa, jolloin tiedosto on lukittu. Tämä on päivämäärä ja kellonaika, johon asti tiedoston tulisi olla vain luku -tilassa. Ennen kuin aikaa muutetaan tällä tavalla, tiedostoa ei voi lukita (ja sitä voidaan muokata tai poistaa).

Tiedoston atime-aikaa voidaan muuttaa NFS- tai CIFS-asiakasohjelmasta kosketuskomennolla:

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

Jos esimerkiksi määrität /data/col1/rl_test/testfile-ajaksi 8.6. klo 07.05:

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

Kuluvasta ajankohdasta tulevaan ajankohtaan on oltava MTree:n vähimmäis- ja enimmäissäilytysaikojen sisällä. Muussa tapauksessa virheitä syntyy, kun tiedostoja muokataan ajoissa:

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

Vastaava ilmoitus näkyy myös Data Domain File System (DDFS) -lokitiedostoissa:

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) -asiakkaat eivät oletusarvoisesti sisällä kosketuskomentoa tai apuohjelmaa, mutta useita tällaisia apuohjelmia on vapaasti ladattavissa useilta kolmansien osapuolten verkkosivustoilta.

Huomautus: Tiedostoja ei voi säilyttää ennen kuin ne on kirjoitettu DDR:ään. Tyhjää tiedostoa ei voi luoda, säilytys lukitsee tiedoston ja kirjoittaa sitten tiedot tiedostoon.

Mitkä varmuuskopiointisovellukset tukevat lukitustiedostojen automaattista säilyttämistä DDR:ään kirjoittamisen jälkeen?
Data Domain Retention Lock on yhteensopiva alan standardien mukaisten NAS-pohjaisten WORM (Write-Once-Read-Many) -protokollien kanssa. Integrointi on hyväksytty arkistosovelluksiin, kuten Symantec Enterprise Vault, SourceOne, Cloud Tiering Appliance tai DiskXtender.

Dell NetWorker tukee sekä hallinto- että vaatimustenmukaisuustiloja.

Kesäkuusta 2024 alkaen uudet Avamar-versiot tukevat sekä Data Domain Retention Lock Compliance että Governance) osana Avamarin Immutable Backups -ominaisuutta. Lisätietoja on alla olevassa artikkelissa ja Avamarin dokumentaatiossa:
Avamar ja Data Domain: Avamar Immutable Backupsin ja Data Domain Compliance Mode Retention Lockin

ottaminen käyttöönOn erittäin tärkeää, että Avamarin "Immutable Backups" -ominaisuuden käyttöönottovaiheita noudatetaan tarkasti. Jos näin ei tehdä, DD:ssä voi olla Avamar MTree, jolle ei voi enää kirjoittaa tai jossa on operatiivisia ongelmia, jotka edellyttävät pitkää palautusta. Avamar ei toimi DD Automatic Retention Lock (ARL) -lukituksen kanssa, eikä ARL:ää saa ottaa käyttöön DD:n Avamar MTree -järjestelmissä.

Asiakkaat, jotka käyttävät muita varmuuskopiointisovelluksia, jotka eivät tue Data Domain Retention Lock -toimintoa natiivisti, voivat myös kehittää mukautettuja komentosarjoja Data Domain Retention Lockin avulla tiedostojen säilytysaikojen asettamiseen manuaalisesti. Varmista tässä tapauksessa, että mukautetut komentosarjat määrittävät tiedoston lukituksen siten, että sen lukitus avautuu, ennen kuin varmuuskopiointisovellus yrittää poistaa tiedoston. Jos näin ei tehdä, varmuuskopiosovellus voi yrittää poistaa lukittuja tiedostoja (mikä epäonnistuu). Tiedosto jätetään DDR: ään määräämättömäksi ajaksi kuluttamaan levytilaa. Katso Data Domainin hallintaopas.

Automaattinen säilytyslukko
Varmuuskopiointisovelluksissa, jotka eivät tue Data Domain -säilytyksen lukitustoimintoa suoraan, asiakkaiden on aina ollut ongelma hyödyntää tätä ominaisuutta. Varmuuskopioinnin järjestelmänvalvojan on määritettävä komentosarjat, joilla määritetään MTree-käsittelyssä juuri käsiteltyjen tiedostojen säilytyslukitus. Lukitus on asetettava niin, että se vanhenee vähän ennen kuin varmuuskopioinnin järjestelmänvalvoja

vanhentuu (ja poistaa).ARL asettaa lukituksen jokaiselle MTreelle kirjoitetulle tiedostolle ominaisuuden käyttöönoton jälkeen, mikä estää tiedoston muuttamisen tai poistamisen tietyksi ajaksi määritetyn harkinta-ajan jälkeen. Tämä tarkoittaa, että ARL ei saa olla käytössä työkuormille tai varmuuskopiointisovelluksille, joiden on päivitettävä joitakin tiedostoja toistuvasti ajan mittaan, esimerkiksi VTL-pooleissa (VTL-nauhatiedostot kirjoitetaan toistuvasti) tai varmuuskopiointisovelluksissa, jotka säilyttävät metatietotietoja asiakkaan varmuuskopiotiedostojen rinnalla (kuten NetWorker tai Avamar). ARL voi näissä tapauksissa lukita tärkeät tiedostot joksikin aikaa, ja kun nämä tiedostot on kirjoitettava myöhemmin muita varmuuskopioita varten, kirjoitus epäonnistuu, samoin mahdolliset myöhemmät varmuuskopiot.

DDOS 6.2.0.20 -versiosta lähtien komentorivillä on ominaisuus, joka voidaan ottaa käyttöön komentoriviliittymässä jokaiselle MTreelle, kun Retention Lock on määritetty, jotta voidaan lukita jokainen käsitelty tiedosto (tietyksi ajaksi), jotta DDOS 6.2.0.20 -versio olisi käytössä. Kun levylle kirjoittamisen valmistumisesta on kulunut ennalta määritetty aika. Näin järjestelmänvalvojien ei enää tarvitse huolehtia säilytyksen manuaalisesta (tai komentosarja) asettamisesta, ja tämä voi tapahtua automaattisesti ilman varmuuskopiointisovelluksen yhteistyötä.
Ennen DDOS 7.8 -versiota DD Boost Logical Storage Units (LSU) -tallennusjärjestelmissä ei voi käyttää automaattista säilytyslukitusta, ja sen ottaminen käyttöön antaa virheilmoituksen, jonka mukaan sitä ei tueta.
Versiosta 7.8 alkaen ARL on tuettu DD Boost LSU:ille.

(ARL:ää, jota käytetään kohde-DD:issä hallittujen tiedostojen replikointiin (MFR), kuten NW-kloonillakin, pitäisi olla riittävän pitkä "automaattisen lukituksen viive", jotta voidaan varmistaa, että varmuuskopioinnin kloonitoiminnot on suoritettu ennen tiedostojen lukituksen asettamista. Esimerkki: Varmuuskopiojoukkoon kuuluvan pienen tiedoston replikointi päättyy nopeasti, kun taas suuremman tiedoston replikointi kestää kauemmin. Ensimmäisen tiedoston säilytys lukitaan, kun suurempi tiedosto on replikoitu ja kohtaa virheen, kun NW yrittää siirtää kaikki varmuuskopiojoukon tiedostot lopulliseen arkistohakemistoon.)

Data Domain VTL ei tue automaattista säilytyksen lukitusta.

Soveltuvissa versioissa mtree retention-lock -komentoriviliittymässä on lisäasetuksia alla esitetyllä tavalla. Tämä ominaisuus voidaan määrittää myös käyttöliittymän kautta valitsemalla Käyttö-vaihtoehdosta "Automaattinen" "Manuaalisen" sijaan:

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

Automaattinen säilytyksen lukitustoiminto lukitsee tiedoston heti, kun ennalta määritetty jäähdyttelyaika on kulunut umpeen (automaattinen lukitusviive). Kun tiedosto on kirjoitettu MTree-käyttöiseen säilytyslukkoon ja lukitus on voimassa "automaattisen säilytysajan" siitä hetkestä lähtien, kun se asetettiin, lukitus tapahtuu, jos arvo on MTreelle määritettyjen "min-retention-period" ja "max-retention-period" -arvojen sisällä.

Katso lisätietoja ominaisuuden käytöstä ja yleistietoja vastaavasta DDOS-hallintaoppaasta. Tämä ominaisuus ei sovellu hyvin tilanteisiin, joissa samaa MTreeä käytetään varmuuskopioiden kohteena, joilla pitäisi olla joko lukitussarjat eri ajanjaksoille, tai varmuuskopiot, joiden pitäisi olla, ja varmuuskopiot, joissa ei pitäisi olla lukitusta alun perinkään.

Mitä lukittua tiedostoa vastaan voi tai ei voi tehdä?

Säilytyslukitut tiedostot ovat vain luku -tilassa, eikä niitä voi muuttaa tai poistaa.
Kun tiedoston säilytysaika päättyy, se "avataan" - lukitsemattomassa tilassa tiedostoa ei vieläkään voi muokata, mutta se voidaan poistaa. DDR ei poista tiedostoa automaattisesti, kun sen säilytysaika päättyy (myöhempi poisto on suoritettava asiakasjärjestelmästä tai varmuuskopiointisovelluksesta).
Kun tietyn tiedoston säilytysaika on asetettu, sitä ei voi lyhentää (eli tiedostoja ei voi aikaistaa).
Säilytysaikoja voidaan kuitenkin pidentää (aikaa voidaan pidentää MTree:n enimmäissäilytysaikaan asti).
Tiedoston omistajuus- ja käyttöoikeusasetuksia voidaan edelleen muokata, kun tiedosto on lukittuna
Säilytyslukossa oleva hakemisto voidaan nimetä uudelleen tai poistaa vain, jos kyseinen hakemisto ei sisällä tiedostoja. Jos hakemisto sisältää tiedostoja (vaikka näitä tiedostoja ei olisikaan lukittu), hakemiston uudelleennimeäminen tai poistaminen epäonnistuu
Vaikka se ei muuttaisi tiedoston sisältöä itse, se ei saa muuttaa sellaisten tiedostojen nimeä (nimetä uudelleen), joilla on lukitusasetus, mutta uudelleennimeäminen on myös kielletty, kun tiedoston lukitus on vanhentunut. Jos tiedostoa ei enää lukita, ainoa sallittu toiminto on poistaminen. Tämä muuttuu DDOS 7.7.4:ssä, kun tiedoston uudelleennimeäminen on sallittua tiedostoille, joita ei ole enää lukittu.

Onko mahdollista poistaa säilytyslukko kokonaan tiedostoa tai tiedostojoukkoa vastaan?
MTrees-tiedostojen säilytyslukitus on mahdollista "palauttaa" (poistaa) hallintotilassa - tämä tehdään seuraavalla komennolla:

# mtree retention-lock revert [path]

Kun tiedoston säilytyslukko on poistettu, sitä voidaan muokata tai se voidaan poistaa normaalisti. Jos tämä komento suoritetaan hakemistossa, säilytyslukitukset poistetaan kaikista kyseisen hakemiston tiedostoista ja kaikista alihakemistoista.

MTrees-tiedostoissa olevien tiedostojen säilytyslukitusta ei voi palauttaa vaatimustenmukaisuustilassa - jos tätä yritetään, näyttöön tulee vastaava virhe:

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

Mitä tapahtuu, jos säilytyslukittua tiedostoa yritetään muokata tai poistaa?
Kaikki yritykset muokata tai poistaa säilytyslukittua tiedostoa aiheuttavat vastaavan "lupa estetty" -virheen:

# 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-lokit osoittavat, että toiminto on epäonnistunut tiedoston säilytyksen lukitsemisen vuoksi:

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.

Onko mahdollista luetella kaikki tiedostot, jotka ovat säilytyslukittuja?
Kyllä, tämän voi tehdä komennolla 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.

Esimerkiksi kaikkien MTree-hakemiston /data/col1/rl_test lukittujen tiedostojen tiedot luetellaan seuraavasti:

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

Onko mahdollista poistaa MTree:n säilytyslukitus kokonaan käytöstä (sen jälkeen, kun se on otettu käyttöön)?
Kyllä, jos MTrees käyttää hallintotilaa, tämä tehdään komennolla '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   -
...

Huomautus: Kun MTree-laitteen säilytyslukko on poistettu käytöstä:

MTreeen tallennettuja uusia tiedostoja ei voi lukita.
Tiedostot, jotka on jo lukittu, pysyvät lukittuina aiemmin määritetyn säilytysajan ajan (toisin sanoen kaikkia lukituksia ei palauteta automaattisesti, kun säilytyslukitus poistetaan käytöstä MTree:tä vastaan).
MTree-tiedostoissa aiemmin olevia lukittuja, joissa säilytyslukitus on poistettu käytöstä, ei voi kumota. Kaikki tarvittavat palautukset on tehtävä ennen pidätyslukon poistamista käytöstä:

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.

Säilytyslukitusta ei voi poistaa käytöstä MTree-laitteessa yhteensopivuustilassa:

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

Voiko replikointia edelleen käyttää MTreesiä vastaan , joissa on säilytyslukitus käytössä?

Kyllä, säilytyslukitut MTreet tai tiedostot voidaan replikoida käyttämällä erilaisia replikointitopologioita:

Hakemistoreplikointi, jota tuetaan vain hallintotilaa käyttävissä tiedostoissa, ei replikoi vähimmäis- ja enimmäissäilytysaikoja kohdejärjestelmään.
MTree-replikointi – voidaan käyttää joko hallinto- tai vaatimustenmukaisuustilan tiedoille, ja se replikoi vähimmäis- ja enimmäissäilytysajat kohdejärjestelmään.
Kokoelman replikointi – voidaan käyttää joko hallinto- tai vaatimustenmukaisuustilan tiedoille, ja se replikoi vähimmäis- ja enimmäissäilytysajat kohdejärjestelmään.

Huomautus: Kohdejärjestelmissä säilytettävät lukituslukot:

Sekä lähde- että kohdejärjestelmässä on oltava vastaavat säilytyslukituslisenssit.
MTree-replikointikontekstien Replication propagate-retention-lock -asetuksena on oltava Enabled.
Hakemistoreplikoinnin avulla replikoiduille tiedostoille vastaavat MTrees-vähimmäis- ja enimmäissäilytysajat on asetettava manuaalisesti kohdejärjestelmässä.

Onko säilytyslukittujen tiedostojen replikointiin muita rajoituksia?

Kyllä, replikointikontekstien uudelleensynkronointi (eli aiemmin määritetyn mutta rikkinäisen kontekstin palauttamista), jossa säilytyslukittuja tietoja käytetään, voi epäonnistua.

Huomautus:

Jos käytetään MTree-replikointia ja kohde-MTree sisältää säilytyslukittuja tiedostoja, joita lähteessä ei ole, uudelleensynkronointi epäonnistuu.
Jos hakemiston replikointi on käytössä ja kohteessa on säilytyslukko, joka on käytössä, mutta lähde ei, uudelleensynkronointi epäonnistuu.

Huomautus: MTree-replikointia käytettäessä uudelleensynkronointi onnistuu seuraavissa tilanteissa, jos kohde-MTree ei sisällä säilytyslukittuja tiedostoja, joita ei ole lähde-DDR:ssä:

Lähde-MTreessä ei ole säilytyslukitusta käytössä, mutta kohteessa on.
Kohteen MTree-laitteessa ei ole säilytyslukitusta käytössä, mutta lähteessä on.

Säilytyksen lukituksen noudattamistilaa ei voi ottaa käyttöön myöskään MTreessä, joka kuuluu jo MTree-replikointikontekstiin. Tässä tilanteessa:

MTree-replikointikonteksti on katkaistava sekä lähde- että kohdejärjestelmissä:

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

Uusi MTree-replikointikonteksti on luotava sekä lähde- että kohdejärjestelmiin:

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

Säilytyksen lukituksen vaatimustenmukaisuustila on otettava käyttöön lähdejärjestelmässä:

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

Juuri luotu replikointikonteksti on synkronoitava uudelleen lähdejärjestelmässä:

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

Voiko säilytyslukitut tiedostot kopioida nopeasti?

Kyllä, säilytyslukitut tiedostot voidaan kopioida nopeasti normaalisti. Jos pikakopiota hallussaan pitävä MTree-kohdekansio on säilytyslukitus käytössä, tiedoston säilytyslukitus säilyy nopeaa kopiota vastaan. Jos kohde-MTree ei ole säilytyslukitus käytössä, nopeaa kopiointia ei ole lukittu.

Onko järjestelmän toiminnoissa muita rajoituksia säilytyslukitusta käytettäessä?

Seuraavat komennot eivät ole sallittuja järjestelmissä, joissa on säilytyksen lukituksen yhteensopivuustila:

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

Tällaisia järjestelmiä ei voi käynnistää yhden käyttäjän tilaan teknisen tuen palautusta varten ilman USB-asemaa ja fyysistä pääsyä järjestelmään.

Seuraavat komennot eivät ole sallittuja MTreesiä vastaan säilytyksen lukituksen noudattamistilassa:

# 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

DDOS 7.3:ssa ja sitä uudemmissa versioissa on kuitenkin säädetty, että asiakkaat voivat poistaa Retention Lock Compliance -toiminnon MTrees-version, jos:

DD:ssä on DDOS 7.3 tai uudempi.
Poistettava RLCE MTree on tyhjä (siinä ei ole yhtään tiedostoa ja hakemistoa).
Järjestelmänvalvoja on läpäissyt Security Officerin todennuksen.

Järjestelmissä, joissa on pitkäaikainen säilytys (Cloud Tier), voidaan myös estää vastaavat tuhoisat komennot, esimerkiksi:

# cloud unit del <cloud unit name>

Huomautus: MTreet, jotka käyttävät säilytyksen lukituksen hallintatilaa (tai jossa tämä tila oli kerran käytössä), voidaan poistaa vain, kun MTree ei sisällä tiedostoja - jos MTreessä on jäljellä tiedostoja, palautetaan virhe.

Onko järjestelmän kellolla merkitystä järjestelmissä, joissa järjestelmän lukitus on käytössä?

Kyllä, säilytyslukon vaatimustenmukaisuutta tukevat järjestelmät mahdollistavat sisäisen "turvakellon", joka estää järjestelmän kellon haitallisen peukaloinnin (mikä voi mahdollistaa säilytyslukittujen tiedostojen poistamisen etuajassa). Suojauskellojen ja järjestelmäkellojen aikoja verrataan säännöllisesti, ja jos niiden välillä on yhden kalenterivuoden aikana kertynyt 2 viikon vinouma, Data Domain File System (DDFS) poistetaan automaattisesti käytöstä, jotta DDR:n tietoihin ei voi pääsyä. Tämä voi tapahtua myös, jos järjestelmän kelloa muutetaan yhtäkkiä ja aikaa muutetaan yli 2 viikkoa.

Tässä tilanteessa DDFS voidaan ottaa uudelleen käyttöön seuraavissa toiminnoissa:

Kirjautuminen DDR:ään
Tarkista, että järjestelmän kello on asetettu oikein.
Tiedostojärjestelmän ottaminen käyttöön:
```
# filesys enable
```
Anna pyydettäessä suojauskäyttäjän tiedot, jotta voit sallia suojauskellon nollaamisen, ja ota DDFS käyttöön.

Voiko järjestelmän kellon synkronoida Active Directoryn kanssa järjestelmissä, joissa on säilytyslukitus yhteensopiva?
Ei, kun säilytyslukituksen noudattaminen on käytössä, CIFS-palvelimet eivät enää synkronoi järjestelmän aikaa Active Directoryn kanssa. Jos järjestelmän ja Active Directoryn välinen aikaero on yli viisi minuuttia, CIFS-palvelin näyttää virhesanoman, kun Active Directory -käyttäjä yrittää kirjautua sisään tai järjestelmä yrittää liittyä Active Directory -domainiin. Määritä Active Directory -aika NTP:llä tämän virheen välttämiseksi.

Tämä eroaa järjestelmistä, joissa säilytyslukituksen noudattaminen ei ole käytössä, mutta Active Directory on käytössä. Tässä tilanteessa NTP:n käyttöönottoa ei suositella, koska Active Directoryn ja NTP:n välillä voi olla aika-asetusristiriitoja.

Mitä voidaan tehdä, jos säilytyslukittuja tiedostoja käyttävä DDR täyttyy kapasiteettiin?

Olettaen, että DDR:ssä ei ole "puhdistettavaa" tilaa (puhdas suoritetaan, mutta järjestelmä pysyy täynnä kapasiteettia), sen sisältö on tarkistettava sen määrittämiseksi,

On tiedostoja, joita ei ole lukittu säilytykseen ja jotka voidaan poistaa.
On tiedostoja, jotka on lukittu hallintotilassa, joiden lukot voidaan palauttaa ja poistaa.

Kun tämä on tehty, puhdistus on suoritettava uudelleen, jotta järjestelmässä on fyysisesti vapaata tilaa. Jos fyysisiä tietoja ei voida poistaa järjestelmästä, DDR:ään on lisättävä fyysistä tallennustilaa ja tiedostojärjestelmää laajennettava (olettaen, että nykyinen DDR tai kokoonpano tukee laajennusta).

Jos järjestelmän ainoat tiedostot on lukittu vaatimustenmukaisuustilassa, lukkoja ei voi palauttaa ja tiedostoja poistaa. Tämän seurauksena tilaa ei voida vapauttaa, ellei:

Kaikkien tai joidenkin tiedostojen säilytysaika saavutetaan. Tämän jälkeen ne voidaan poistaa ja puhdistaa (kuten edellä on kuvattu).
Järjestelmä asennetaan uudelleen USB-asemasta (mikä aiheuttaa kaikkien DDR: n tietojen menetyksen).
Järjestelmään lisätään fyysistä tallennustilaa (kuten edellä on kuvattu).

Huomautus: DDR on täysin mahdollista täyttää kokonaan tiedostoilla, jotka on lukittu vaatimustenmukaisuustilassa. Tässä tilanteessa järjestelmänvalvoja tai tekninen tuki ei voi tehdä mitään tilan vapauttamiseksi (eli ei ole matalan tason toimintoa, jolla vaatimustenmukaisuustilan lukitukset voitaisiin poistaa/palauttaa ja vastaavia tiedostoja poistaa etuajassa).

文書のプロパティ

影響を受ける製品

Data Domain, Data Domain Retention Lock

製品

Data Domain

最後に公開された日付

18 7月 2024

バージョン

文書の種類

Solution

トップに戻る

ようこそ

Dellへようこそ

Data Domain: Säilytyslukon usein kysytyt kysymykset

概要: Tämä artikkeli sisältää yleiskatsauksen Data Domain Retention Lock (RL) -toiminnoista ja selittää hallinnan ja vaatimustenmukaisuustilan määritysten ja käytön erot.

文書の内容

現象

原因

解決方法

文書のプロパティ

影響を受ける製品

製品

最後に公開された日付

バージョン

文書の種類