กลยุทธ์การสำรองข้อมูลสำหรับที่เก็บข้อมูล AWS S3


93

ฉันกำลังมองหาคำแนะนำหรือแนวทางปฏิบัติที่ดีที่สุดในการสำรองข้อมูลถัง S3
วัตถุประสงค์ของการสำรองข้อมูลจาก S3 คือเพื่อป้องกันข้อมูลสูญหายเนื่องจากสิ่งต่อไปนี้:

  1. ปัญหา S3
  2. ปัญหาที่ฉันลบข้อมูลนี้ออกจาก S3 โดยไม่ได้ตั้งใจ

หลังจากการตรวจสอบแล้วฉันพบตัวเลือกต่อไปนี้:

  1. ใช้การกำหนดเวอร์ชันhttp://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html
  2. คัดลอกจากที่เก็บข้อมูล S3 หนึ่งไปยังอีกถังหนึ่งโดยใช้ AWS SDK
  3. สำรองข้อมูลไปที่ Amazon Glacier http://aws.amazon.com/en/glacier/
  4. สำรองข้อมูลไปยังเซิร์ฟเวอร์ที่ใช้งานจริงซึ่งสำรองไว้เอง

ฉันควรเลือกตัวเลือกใดและการจัดเก็บข้อมูลเฉพาะใน S3 จะปลอดภัยเพียงใด ต้องการรับฟังความคิดเห็นของคุณ
ลิงค์ที่มีประโยชน์:


โปรดยอมรับstackoverflow.com/a/40033265/1586965
samthebest

คำตอบ:


63

โพสต์ครั้งแรกในบล็อกของฉัน: http://eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/

ซิงค์ S3 Bucket ของคุณกับเซิร์ฟเวอร์ EC2 เป็นระยะ

สิ่งนี้สามารถทำได้อย่างง่ายดายโดยใช้ยูทิลิตีบรรทัดคำสั่งหลายรายการที่ทำให้สามารถซิงค์บัคเก็ต S3 ระยะไกลกับระบบไฟล์ภายในเครื่องได้

s3cmd
ตอนแรกs3cmdดูเด่นสุด ๆ อย่างไรก็ตามหลังจากลองใช้กับถัง S3 ขนาดมหึมาของฉัน - มันล้มเหลวในการปรับขนาดเกิดข้อผิดพลาดกับไฟล์Segmentation fault. แม้ว่ามันจะทำงานได้ดีกับถังขนาดเล็ก เนื่องจากมันไม่ได้ผลกับถังขนาดใหญ่ฉันจึงหาทางเลือกอื่น

s4cmd
ทางเลือกใหม่แบบมัลติเธรดสำหรับs3cmd. อย่างไรก็ตามดูมีแนวโน้มมากยิ่งขึ้นฉันสังเกตเห็นว่ามันยังคงดาวน์โหลดไฟล์ซ้ำที่มีอยู่แล้วในระบบไฟล์ในเครื่อง นั่นไม่ใช่พฤติกรรมที่ฉันคาดหวังจากคำสั่งซิงค์ ควรตรวจสอบว่ามีไฟล์ระยะไกลในเครื่องอยู่แล้วหรือไม่ (การตรวจสอบแฮช / ขนาดไฟล์จะเรียบร้อย) และข้ามไปในการซิงค์ครั้งถัดไปที่รันบนไดเร็กทอรีเป้าหมายเดียวกัน ฉันเปิดปัญหา ( bloomreach / s4cmd / # 46 ) เพื่อรายงานพฤติกรรมแปลก ๆ นี้ ในระหว่างนี้ฉันก็ออกเดินทางเพื่อหาทางเลือกอื่น

awscliและจากนั้นผมพบว่า
awscliนี่คืออินเทอร์เฟซบรรทัดคำสั่งอย่างเป็นทางการของ Amazon สำหรับการโต้ตอบกับบริการคลาวด์ต่างๆรวมถึง S3

AWSCLI

มันมีคำสั่งซิงค์ประโยชน์ที่รวดเร็วและง่ายดายดาวน์โหลดไฟล์ถังระยะไกลไปยังระบบแฟ้มในท้องถิ่นของคุณ

$ aws s3 ซิงค์ s3: // your-bucket-name / home / ubuntu / s3 / your-bucket-name /

สิทธิประโยชน์:

  • ปรับขนาดได้ - รองรับบัคเก็ต S3 ขนาดใหญ่
  • มัลติเธรด - ซิงค์ไฟล์ได้เร็วขึ้นโดยใช้หลายเธรด
  • สมาร์ท - ซิงค์เฉพาะไฟล์ใหม่หรือไฟล์ที่อัปเดต
  • รวดเร็ว - ด้วยลักษณะมัลติเธรดและอัลกอริธึมการซิงค์อัจฉริยะ

การลบโดยบังเอิญ

สะดวกsyncคำสั่งจะไม่ลบไฟล์ในโฟลเดอร์ปลายทาง (ระบบไฟล์ในเครื่อง) หากไฟล์เหล่านั้นหายไปจากแหล่งที่มา (S3 ที่เก็บข้อมูล) และในทางกลับกัน เหมาะสำหรับการสำรองข้อมูล S3 - ในกรณีที่ไฟล์ถูกลบออกจากที่เก็บข้อมูลการซิงค์ใหม่จะไม่ลบไฟล์เหล่านั้นในเครื่อง และในกรณีที่คุณลบไฟล์ในเครื่องไฟล์นั้นจะไม่ถูกลบออกจากที่เก็บข้อมูลต้นทางเช่นกัน

การตั้งค่า awscli บน Ubuntu 14.04 LTS

awscliขอเริ่มต้นด้วยการติดตั้ง มีหลายวิธีในการดำเนินการนี้อย่างไรก็ตามฉันพบว่าการติดตั้งทำได้ง่ายที่สุดผ่านทางapt-getไฟล์.

$ sudo apt-get ติดตั้ง awscli

การกำหนดค่า

ต่อไปเราต้องกำหนดค่าawscliด้วยรหัสคีย์การเข้าถึงและรหัสลับซึ่งคุณต้องได้รับจากIAMโดยการสร้างผู้ใช้และแนบนโยบายAmazonS3ReadOnlyAccess วิธีนี้จะป้องกันไม่ให้คุณหรือใครก็ตามที่สามารถเข้าถึงข้อมูลรับรองเหล่านี้ลบไฟล์ S3 ของคุณได้ ตรวจสอบให้แน่ใจว่าได้ป้อนภูมิภาค S3 ของคุณเช่นus-east-1.

$ aws กำหนดค่า

AWs กำหนดค่า

การเตรียมการ

มาเตรียมไดเร็กทอรีสำรอง S3 ในเครื่องโดยเฉพาะใน/home/ubuntu/s3/{BUCKET_NAME}. อย่าลืมแทนที่{BUCKET_NAME}ด้วยชื่อที่เก็บข้อมูลจริงของคุณ

$ mkdir -p / home / ubuntu / s3 / {BUCKET_NAME}

การซิงค์เริ่มต้น

ไปข้างหน้าและซิงค์ที่เก็บข้อมูลเป็นครั้งแรกด้วยคำสั่งต่อไปนี้:

$ aws s3 ซิงค์ s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

สมมติว่ามีที่เก็บข้อมูลข้อมูลรับรองและภูมิภาคของ AWS ถูกต้องและโฟลเดอร์ปลายทางถูกต้องawscliจะเริ่มดาวน์โหลดที่เก็บข้อมูลทั้งหมดไปยังระบบไฟล์ภายใน

ขึ้นอยู่กับขนาดของที่เก็บข้อมูลและการเชื่อมต่ออินเทอร์เน็ตของคุณอาจใช้เวลาไม่กี่วินาทีถึงชั่วโมง เมื่อเสร็จแล้วเราจะดำเนินการต่อและตั้งค่างาน cron อัตโนมัติเพื่อให้สำเนาที่เก็บข้อมูลในเครื่องเป็นปัจจุบันอยู่เสมอ

การตั้งค่างาน Cron

สร้างsync.shไฟล์ใน/home/ubuntu/s3:

$ nano /home/ubuntu/s3/sync.sh

คัดลอกและวางรหัสต่อไปนี้ลงในsync.sh:

#! / bin / ช

# สะท้อนวันที่และเวลาปัจจุบัน

ก้อง '-----------------------------'
วันที่
ก้อง '-----------------------------'
ก้อง ''

# การเริ่มต้นสคริปต์ Echo
echo 'กำลังซิงค์ที่เก็บ S3 ระยะไกล ... '

# เรียกใช้คำสั่งการซิงค์จริง (แทนที่ {BUCKET_NAME} ด้วยชื่อที่เก็บข้อมูล S3 ของคุณ)
/ usr / bin / aws s3 ซิงค์ s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

# สคริปต์ Echo เสร็จสมบูรณ์
สะท้อน 'การซิงค์เสร็จสมบูรณ์'

อย่าลืมแทนที่{BUCKET_NAME}ด้วยชื่อที่เก็บข้อมูล S3 ของคุณสองครั้งตลอดทั้งสคริปต์

เคล็ดลับสำหรับมือโปร:คุณควรใช้/usr/bin/awsเพื่อเชื่อมโยงกับawsไบนารีเนื่องจากcrontabรันคำสั่งในสภาพแวดล้อมเชลล์ที่ จำกัด และจะไม่สามารถค้นหาไฟล์ปฏิบัติการได้ด้วยตัวเอง

ถัดไปให้ตรวจสอบการใช้สคริปต์เพื่อที่จะสามารถดำเนินการโดยchmodcrontab

$ sudo chmod + x /home/ubuntu/s3/sync.sh

ลองเรียกใช้สคริปต์เพื่อให้แน่ใจว่าใช้งานได้จริง:

$ /home/ubuntu/s3/sync.sh

ผลลัพธ์ควรคล้ายกับสิ่งนี้:

เอาท์พุท sync.sh

ต่อไปเรามาแก้ไขผู้ใช้ปัจจุบันcrontabโดยดำเนินการคำสั่งต่อไปนี้:

$ crontab -e

หากนี่เป็นครั้งแรกที่คุณดำเนินการcrontab -eคุณจะต้องเลือกตัวแก้ไขที่ต้องการ ขอแนะนำให้เลือกnanoเนื่องจากเป็นวิธีที่ง่ายที่สุดสำหรับผู้เริ่มต้นในการทำงาน

ความถี่ในการซิงค์

เราต้องบอกcrontabความถี่ในการรันสคริปต์ของเราและตำแหน่งที่สคริปต์อยู่บนระบบไฟล์โลคัลโดยการเขียนคำสั่ง รูปแบบสำหรับคำสั่งนี้มีดังนี้:

คำสั่ง mh dom mon dow

คำสั่งต่อไปนี้กำหนดค่าcrontabให้รันsync.shสคริปต์ทุก ๆ ชั่วโมง (ระบุผ่านพารามิเตอร์นาที: 0 และชั่วโมง: *) และกำหนดให้ไพพ์เอาต์พุตของสคริปต์ไปยังsync.logไฟล์ในs3ไดเร็กทอรีของเรา:

0 * * * * /home/ubuntu/s3/sync.sh> /home/ubuntu/s3/sync.log

คุณควรเพิ่มบรรทัดนี้ที่ด้านล่างของcrontabไฟล์ที่คุณกำลังแก้ไข จากนั้นไปข้างหน้าและบันทึกแฟ้มไว้บนฮาร์ดดิสก์โดยการกดCtrl + Wและจากนั้นใส่ จากนั้นคุณสามารถออกnanoได้โดยการกดCtrl + X crontabตอนนี้จะเรียกใช้งานการซิงค์ทุกชั่วโมง

เคล็ดลับสำหรับมืออาชีพ:คุณสามารถตรวจสอบได้ว่างาน cron รายชั่วโมงกำลังดำเนินการสำเร็จโดยการ/home/ubuntu/s3/sync.logตรวจสอบตรวจสอบเนื้อหาสำหรับวันที่และเวลาดำเนินการและตรวจสอบบันทึกเพื่อดูว่ามีการซิงค์ไฟล์ใหม่ใดบ้าง

ทุกชุด! ตอนนี้ที่เก็บข้อมูล S3 ของคุณจะซิงค์กับเซิร์ฟเวอร์ EC2 ของคุณทุก ๆ ชั่วโมงโดยอัตโนมัติและคุณควรจะไป โปรดทราบว่าเมื่อเวลาผ่านไปเนื่องจากบัคเก็ต S3 ของคุณมีขนาดใหญ่ขึ้นคุณอาจต้องเพิ่มขนาดโวลุ่ม EBS ของเซิร์ฟเวอร์ EC2 เพื่อรองรับไฟล์ใหม่ คุณสามารถเพิ่มขนาดเสียง EBS ได้ตลอดเวลาโดยทำตามคำแนะนำนี้


ฉันได้ฝากคำถามไว้ในบล็อกของคุณ แต่ฉันสงสัยว่ามีวิธีซิงค์ข้อมูลเมตาด้วยหรือไม่?
Devology Ltd

@Devology Ltd น่าเสียดายที่ฉันไม่มีโอกาสทำงานกับข้อมูลเมตาของวัตถุ S3 จากการค้นหาโดย Google อย่างรวดเร็วดูเหมือนว่าจะไม่awscliรองรับการซิงค์สิ่งนี้โดยอัตโนมัติในaws s3 syncคำสั่ง ดูเหมือนว่าคุณอาจต้องใช้สิ่งนี้ด้วยตนเอง
Elad Nava

ขอบคุณ @Ekad Nava - ฉันขอขอบคุณที่ยืนยันสิ่งที่ฉันเชื่อว่าเป็นเช่นนั้น
Devology Ltd

1
นี่คือ @EladNava ที่ยอดเยี่ยมขอบคุณสำหรับการแบ่งปันยังคงมีความเกี่ยวข้องในปี 2020!
user1130176

คำตอบนี้ไม่เหมาะเมื่อคุณมีไฟล์เป็นล้าน ๆ ไฟล์ กลายเป็นราคาแพงมากช้าและบางครั้งก็เป็นไปไม่ได้ - เนื่องจากข้อ จำกัด ของระบบไฟล์
Psychozoic

30

เมื่อพิจารณาถึงลิงก์ที่เกี่ยวข้องซึ่งอธิบายว่า S3 มีความทนทาน 99.999999999% ฉันขอทิ้งความกังวลของคุณ # 1 อย่างจริงจัง.

ตอนนี้ถ้า # 2 เป็นกรณีการใช้งานที่ถูกต้องและเป็นข้อกังวลอย่างแท้จริงสำหรับคุณฉันจะยึดติดกับตัวเลือก # 1 หรือ # 3 อย่างแน่นอน อันไหนของพวกเขา? ขึ้นอยู่กับคำถามบางประการ:

  • คุณต้องการคุณสมบัติการกำหนดเวอร์ชันอื่น ๆ หรือเพียงเพื่อหลีกเลี่ยงการเขียนทับ / ลบโดยไม่ได้ตั้งใจ?
  • ค่าใช้จ่ายเพิ่มเติมที่กำหนดโดยการกำหนดเวอร์ชันราคาไม่แพงหรือไม่?
  • Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. ตกลงสำหรับคุณหรือไม่?

เว้นแต่การใช้พื้นที่เก็บข้อมูลของคุณจะใหญ่มากฉันจะยึดติดกับการกำหนดเวอร์ชันถัง ด้วยวิธีนี้คุณจะไม่ต้องใช้รหัส / เวิร์กโฟลว์ใด ๆ เพิ่มเติมในการสำรองข้อมูลไปยัง Glacier ไปยังที่เก็บข้อมูลอื่น ๆ หรือแม้แต่เซิร์ฟเวอร์อื่น ๆ (ซึ่งเป็นทางเลือกที่ไม่ดีจริงๆ IMHO โปรดลืมมันไป)


4
@SergeyAlekseev ถ้า Glacier เป็นสิ่งที่เหมาะกับคุณการตั้งค่ากฎวงจรชีวิตในถังที่เก็บไฟล์ของคุณไปยังธารน้ำแข็งโดยอัตโนมัติได้อย่างรวดเร็ว โดยจะยังคงปรากฏในที่เก็บข้อมูล (ใน UI ของเว็บ) แต่คลาสพื้นที่เก็บข้อมูลจะเปลี่ยนจากมาตรฐานเป็นธารน้ำแข็ง ฉันย้ายไฟล์ที่ผ่านการประมวลผลจากที่เก็บข้อมูลหลักไปยังที่เก็บข้อมูล "เสร็จสิ้น" และที่เก็บข้อมูลที่ทำเสร็จแล้วจะมีกฎของวงจรชีวิตที่เก็บไฟล์ที่มีอายุมากกว่า 1 วัน นี่คือไฟล์ข้อมูลที่ฉันอาจจะไม่เคยสัมผัสอีกเลย แต่ต้องเก็บไว้ให้ไคลเอนต์
แดน

28
ฉันไม่คิดว่า 99.999999999% เป็นเหตุผลที่ดีพอที่จะเต็มสแต็ค AWS ในพื้นที่จัดเก็บ / สำรองข้อมูล ฉันไม่ได้พูดถึงเงิน 0.0000000001% ที่เหลืออยู่ แต่หากมีสิ่งที่ไม่คาดคิดเกิดขึ้นอย่างมากก็รู้สึกอึดอัดใจที่มีธุรกิจทั้งหมดของคุณนอนอยู่ที่ไหนสักแห่ง โดยไม่คาดคิดอาจเป็นไปได้ว่าสหรัฐฯกำลังทำสงครามกับประเทศใดประเทศหนึ่ง Amazon ถูกแฮ็กโดยสิ้นเชิง (เปรียบเทียบ Sony) ฯลฯ
Augustin Riedinger

11
ฉันจะตอบกลับ @AugustinRiedinger เกี่ยวกับเรื่องนี้: "ปัญหา S3" อาจเป็นเพราะคำจำกัดความบางอย่างที่คุณไม่รู้ (เช่นปัญหาของรัฐบาล) ซึ่งอาจทำให้สมมติฐานที่ใช้ S3 SLA เช่น 99.99 ... เป็นไปไม่ได้ เมื่อทำอะไรในระยะยาวรวมถึงการสำรองข้อมูลของคุณการกระจายความเสี่ยงเป็นแนวทางปฏิบัติที่ดีหากไม่ควรเป็นสิ่งที่จำเป็นต้องมี
lajarre

2
ฉันยอมรับว่าคะแนนของคุณถูกต้อง แต่จากตัวเลือกที่ OP กำหนด (เกือบทั้งหมดรวมถึงทางเลือกของ AWS สำหรับปัญหา) ฉันไม่คิดว่า "ปัญหา S3" จะกว้างเท่าที่พวกคุณกำลังขยาย ดีที่จะเห็นความคิดที่กว้างขึ้นแม้ว่า
Viccari

4
คำตอบเก่า แต่ฉันรู้สึกราวกับว่าต้องพูดถึงเหตุการณ์ล่าสุด (-ish) "วันที่ Amazon ทำลายเว็บ" ซึ่งเป็นเทคโนโลยีลบเซิร์ฟเวอร์ S3 ส่วนใหญ่โดยไม่ได้ตั้งใจ แม้ในช่วง 24 ชั่วโมงนั้นปัญหาคือการเข้าถึง ไม่ใช่ข้อมูลสูญหาย ไม่มีการสูญเสียข้อมูลอย่างแน่นอนแม้จะมีการลบเซิร์ฟเวอร์จำนวนมากและพวกเขาก็ยังจัดการได้ดีภายใน SLA
Oberst

14

คุณสามารถสำรองข้อมูล S3 ของคุณโดยใช้วิธีการต่อไปนี้

  1. กำหนดเวลากระบวนการสำรองข้อมูลโดยใช้ AWS datapipeline ซึ่งสามารถทำได้ 2 วิธีดังต่อไปนี้:

    ก. ใช้ copyActivity ของ datapipeline ซึ่งคุณสามารถคัดลอกจากที่เก็บข้อมูล s3 หนึ่งไปยังที่เก็บข้อมูล s3 อื่น

    ข. การใช้ ShellActivity ของ datapipeline และคำสั่ง "S3distcp" เพื่อทำสำเนาซ้ำของโฟลเดอร์ s3 แบบเรียกซ้ำจากที่เก็บข้อมูลไปยังอีกโฟลเดอร์หนึ่ง (แบบขนาน)

  2. ใช้การกำหนดเวอร์ชันภายในที่เก็บข้อมูล S3 เพื่อรักษาเวอร์ชันต่างๆของข้อมูล

  3. ใช้ธารน้ำแข็งเพื่อสำรองข้อมูลของคุณ (ใช้เมื่อคุณไม่จำเป็นต้องคืนค่าการสำรองข้อมูลอย่างรวดเร็วไปยังที่เก็บข้อมูลดั้งเดิม (ต้องใช้เวลาพอสมควรในการเรียกคืนข้อมูลจากธารน้ำแข็งเนื่องจากข้อมูลถูกจัดเก็บในรูปแบบบีบอัด) หรือเมื่อคุณต้องการบันทึก ค่าใช้จ่ายบางอย่างโดยหลีกเลี่ยงการใช้ถัง s3 สำรองอื่น ๆ ) ตัวเลือกนี้สามารถตั้งค่าได้อย่างง่ายดายโดยใช้กฎอายุการใช้งานบนถัง s3 ไปๆมาๆซึ่งคุณต้องการสำรองข้อมูล

ตัวเลือกที่ 1 สามารถเพิ่มความปลอดภัยให้คุณได้มากขึ้นในกรณีที่คุณลบที่เก็บข้อมูล s3 ดั้งเดิมของคุณโดยไม่ได้ตั้งใจและข้อดีอีกประการหนึ่งคือคุณสามารถจัดเก็บข้อมูลสำรองของคุณในโฟลเดอร์ข้อมูลในที่เก็บข้อมูล s3 อื่นด้วยวิธีนี้คุณจะทราบว่าคุณมีข้อมูลใดในวันใดวันหนึ่งและสามารถทำได้ คืนค่าการสำรองข้อมูลวันที่ที่ระบุ ทุกอย่างขึ้นอยู่กับคุณใช้กรณี


@David: ตามที่เดวิดแนะนำในโซลูชันของเขาด้านล่างว่าอาจมีสคริปต์ที่สำรองถัง s3 ทุกวันหรือทุกสัปดาห์สิ่งนี้สามารถบรรลุได้อย่างง่ายดายด้วยจุดแรกของฉัน (ข้อมูล AWS - ซึ่งช่วยให้คุณสามารถกำหนดเวลากระบวนการสำรองข้อมูลได้ทุกวัน , รายสัปดาห์ ฯลฯ ). ฉันอยากจะแนะนำให้มีการค้นหาข้อมูลใน AWS datapipeline
Varun

สิ่งนี้แสดงให้เห็นถึงคำมั่นสัญญาบางประการเนื่องจากไม่ได้อาศัยแนวทางที่ล้าสมัยซึ่งไม่ได้ใช้ประโยชน์สูงสุดจากระบบคลาวด์ (อ่าน: crons) นอกจากนี้ Data Pipeline ยังมีการลองใหม่โดยอัตโนมัติและเป็นบริการที่มีการจัดการ (แบบไร้เซิร์ฟเวอร์)
Felipe Alvarez

13

แล้วการใช้คุณลักษณะการจำลองแบบข้ามภูมิภาคที่พร้อมใช้งานบนบัคเก็ต S3 นั้นเป็นอย่างไร บทความที่มีประโยชน์เกี่ยวกับคุณลักษณะนี้มีดังต่อไปนี้


จะเป็นอย่างไรหากคุณลบไฟล์ในภูมิภาคหนึ่งไม่ควรจำลองซ้ำในอีกภูมิภาคหนึ่ง
michelem

S3 ไม่ได้ลบซ้ำ, ตรวจสอบการเชื่อมโยงนี้docs.aws.amazon.com/AmazonS3/latest/dev/...
ᐅ devrimbaris

9

คุณคิดว่าจะมีวิธีที่ง่ายกว่าในตอนนี้ในการเก็บสำรองข้อมูลส่วนเพิ่มบางประเภทไว้ในภูมิภาคที่แตกต่างกัน

คำแนะนำทั้งหมดข้างต้นไม่ใช่วิธีง่ายๆหรือสวยหรู ฉันไม่คิดว่าธารน้ำแข็งเป็นตัวเลือกจริงๆเพราะฉันคิดว่านั่นเป็นโซลูชันการเก็บถาวรมากกว่าแล้วก็เป็นโซลูชันสำรอง เมื่อฉันคิดว่าการสำรองข้อมูลฉันคิดว่าการกู้คืนความเสียหายจากนักพัฒนารุ่นเยาว์ที่ลบที่เก็บข้อมูลซ้ำ ๆ หรืออาจเป็นการใช้ประโยชน์หรือข้อบกพร่องในแอปของคุณที่ลบสิ่งต่างๆออกจาก s3

สำหรับฉันแล้วทางออกที่ดีที่สุดคือสคริปต์ที่สำรองข้อมูลที่เก็บข้อมูลหนึ่งไปยังอีกภูมิภาคหนึ่งวันละหนึ่งครั้งต่อสัปดาห์ดังนั้นหากมีสิ่งที่เลวร้ายเกิดขึ้นคุณสามารถเปลี่ยนภูมิภาคได้ ฉันไม่มีการตั้งค่าเช่นนี้ฉันได้ตรวจสอบแล้วว่ายังไม่ได้ดำเนินการดังกล่าวทำให้ต้องใช้ความพยายามเล็กน้อยในการดำเนินการนี้ซึ่งเป็นเหตุผลว่าทำไมฉันจึงหวังว่าจะมีโซลูชันสต็อกให้ใช้


เห็นด้วย เป็นเรื่องที่น่าสนใจเมื่อคุณเจาะลึกลงไปใน S3 (แม้กระทั่ง CRR ซึ่งสร้างขึ้นในการจำลองแบบ) มีช่องโหว่ขนาดใหญ่สำหรับการกู้คืนระบบ ตัวอย่างเช่นคุณไม่สามารถกู้คืนที่เก็บข้อมูลประวัติเวอร์ชันของไฟล์ข้อมูลเมตา (โดยเฉพาะวันที่แก้ไขล่าสุด) เป็นต้นสถานการณ์การกู้คืนทั้งหมดที่มีอยู่ในขณะนี้คือการกู้คืนบางส่วน
Paul Jowett

7

ในขณะที่มีการโพสต์คำถามนี้เมื่อไม่นานมานี้ฉันคิดว่าการพูดถึงการป้องกันการลบ MFAด้วยโซลูชันอื่น ๆ เป็นสิ่งสำคัญ OP กำลังพยายามแก้ไขสำหรับการลบข้อมูลโดยไม่ได้ตั้งใจ การพิสูจน์ตัวตนแบบหลายปัจจัย (MFA) ปรากฏในสองสถานการณ์ที่แตกต่างกันที่นี่ -

  1. การลบเวอร์ชันออบเจ็กต์อย่างถาวร - เปิดใช้งานการลบ MFA ในการกำหนดเวอร์ชันของที่เก็บข้อมูล

  2. การลบที่เก็บข้อมูลโดยไม่ได้ตั้งใจ - ตั้งค่านโยบายที่เก็บข้อมูลที่ปฏิเสธการลบโดยไม่มีการตรวจสอบสิทธิ์ MFA

จับคู่กับการจำลองแบบข้ามภูมิภาคและการกำหนดเวอร์ชันเพื่อลดความเสี่ยงของข้อมูลสูญหายและปรับปรุงสถานการณ์การกู้คืน

นี่คือบล็อกโพสต์ในหัวข้อนี้พร้อมรายละเอียดเพิ่มเติม


0

ถ้าเรามีข้อมูลมากเกินไป หากคุณมีที่เก็บข้อมูลแล้วในครั้งแรกการซิงค์จะใช้เวลามากเกินไปในกรณีของฉันฉันมี 400GB ครั้งแรกใช้เวลา 3 ชม. ดังนั้นฉันคิดว่าเราสามารถทำให้การจำลองเป็นทางออกที่ดีสำหรับการสำรองข้อมูล S3 Bucket


ฉันกำลังจะย้ายประมาณ 7TB ไปไว้ในที่เก็บข้อมูลและกำลังพยายามหาทางเลือกที่ดีที่สุด ... ฉันคิดว่าฉันต้องการสิ่งที่ดีกว่าการซิงค์ ฉันสงสัยว่าการใช้ไปป์ไลน์เพื่อคัดลอกข้อมูลไปยังธารน้ำแข็งเวอร์ชัน GCS อาจให้ความปลอดภัยโดยรวมที่ดีที่สุดหรือไม่
Brendon Whateley

AWS DataSync อาจเป็นตัวเลือกที่นี่
Felipe Alvarez
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.