In het begin kan dit een beetje paradoxaal lijken; S3 wordt immers meestal gebruikt als back-up voor andere services. Maar het biedt geen bescherming tegen onbedoelde verwijderingen of overschrijvingen, en voor bedrijfskritieke gegevens kunt u extra betalen om de bucket in verschillende regio's te laten repliceren.
Voorkom onbedoelde verwijdering met objectversiebeheer
Laten we eerst één ding duidelijk maken: de gegevens in S3 zijn ongelooflijk veilig. Het wordt gebruikt voor back-ups, dus het heeft weinig zin om een back-up van uw back-up te maken, tenzij u echt paranoïde bent over het verliezen van uw gegevens.
En hoewel S3-gegevens absoluut veilig zijn voor individuele schijfstoringen als gevolg van RAID en andere back-ups, zijn ze ook veilig voor rampscenario's zoals wijdverbreide uitval of magazijnstoringen. In tegenstelling tot door EBS ondersteunde datavolumes, die op één plaats worden opgeslagen en volledig kunnen uitvallen, maakt S3 al “back-ups van uw gegevens.” Gegevens in S3 worden opgeslagen in drie of meer Beschikbaarheidszones, wat betekent dat zelfs in het geval dat een ervan uitvalt, u nog twee back-ups hebt.
Waartegen S3 je niet beschermt, ben je zelf. Het is veel, veel waarschijnlijker dat u, of iemand anders met toegang, per ongeluk iets verwijdert of een belangrijk object overschrijft met afvalgegevens. Dit is het scenario waar u zich zorgen over zou moeten maken.
Om hiertegen te beschermen, heeft S3 een functie genaamd Object Versioning. Het slaat elke verschillende versie van elk object op, dus als u het per ongeluk overschrijft, kunt u een eerdere versie herstellen. U kunt ook op elk gewenst moment eerdere versies ophalen door dat als parameter door te geven aan het GET-verzoek.
Advertentie
Als versiebeheer is ingeschakeld, in plaats van objecten rechtstreeks te verwijderen, markeert S3 het object met een &# 8220;Verwijdermarkering” dat zorgt ervoor dat het doet alsof het weg is, maar in het geval dat je het niet wilde verwijderen, is het omkeerbaar.
Met een levenscyclusbeleid (meer daarover hieronder) zou het beheer van bucketversies niet veel extra moeten kosten, aangezien oude versies niet lang worden bewaard. Het is standaard uitgeschakeld, maar zowel Amazon als wij raden u aan het in te schakelen als u de opslaguitbreiding kunt besparen.
Om het in te schakelen, opent u de instellingen van de bucket en klikt u op & #8220;Eigenschappen,” en klik op “Bewerken” op Bucket Versioning.
Vanaf hier kunt u eenvoudig het aan.
Uw portemonnee opslaan met levenscyclusregels
Natuurlijk neemt het opslaan van meerdere kopieën van objecten veel meer ruimte in beslag, vooral als u regelmatig gegevens overschrijft. U hoeft deze oude versies waarschijnlijk niet voor de rest van de eeuwigheid te bewaren, dus u kunt uw portemonnee een plezier doen door een Lifecycle-regel in te stellen die de oude versies na enige tijd zal verwijderen.
Onder Beheer > Life Cycle Configuration, voeg een nieuwe regel toe. De twee beschikbare opties zijn het verplaatsen van oude objecten naar een niet-frequente toegangslaag of ze permanent verwijderen nadat
In het geval je bang bent dat je verkeerd hebt geklikt en deze regel gaat werkgegevens verwijdert, ziet u onderaan dat de regelacties pas 30 dagen nadat een object niet-actueel is geworden, van toepassing zijn. Er is geen regel die werkgegevens permanent verwijdert, alleen laat deze verlopen, wat kan worden hersteld.
Repliceer de bucket over verschillende regio's
Als je echt een back-up wilt maken van de hele S3-bucket, kun je dat doen met een andere bucket en een replicatieregel. Deze regel repliceert automatisch alle acties in de doelbucket.
Advertentie
U kunt deze instellen vanuit de “Replicatie” tabblad onder “Beheer.”
Stel de bronconfiguratie in (ofwel de hele bucket of een prefix/tag) en stel de doelbucket in:
U moet een IAM-rol maken voor replicatie; S3 zal de configuratie afhandelen, geef het gewoon een naam.
Klik op “Volgende,” en klik op “Opslaan.” De regel moet onmiddellijk actief zijn; je kunt het uploaden van een object testen, en je zou het moeten zien gerepliceerd naar de bestemmingsbucket, dan zul je zien dat de replicatiestatustag verandert in VOLTOOID.