AWS S3 paketi için yedekleme stratejileri


92

S3 klasörünü yedeklemek için bazı öneriler veya en iyi uygulama arıyorum.
S3'ten veri yedeklemenin amacı, aşağıdakiler nedeniyle veri kaybını önlemektir:

  1. S3 sorunu
  2. bu verileri yanlışlıkla S3'ten sildiğimde sorun

Biraz araştırmadan sonra aşağıdaki seçenekleri görüyorum:

  1. Http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html sürüm oluşturmayı kullanın
  2. AWS SDK kullanarak bir S3 klasöründen diğerine kopyalama
  3. Amazon Glacier'a yedekleme http://aws.amazon.com/en/glacier/
  4. Kendisi yedeklenen üretim sunucusuna yedekleme

Hangi seçeneği seçmeliyim ve verileri yalnızca S3'te depolamak ne kadar güvenli olur? Fikirlerinizi duymak ister misiniz?
Bazı yararlı bağlantılar:


Yanıtlar:


63

İlk olarak blogumda yayınlandı: http://eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/

S3 Paketinizi Düzenli Olarak EC2 Sunucusuna Senkronize Edin

Bu, uzaktaki bir S3 klasörünü yerel dosya sistemiyle eşitlemeyi mümkün kılan birden çok komut satırı yardımcı programını kullanarak kolayca başarılabilir.

s3cmd
İlk başta s3cmdson derece umut verici görünüyordu. Ancak, muazzam S3 klasörümde denedikten sonra ölçeklenemedi, bir Segmentation fault. Yine de küçük kovalarda iyi çalıştı. Büyük kovalar için işe yaramadığı için bir alternatif bulmaya başladım.

s4cmd
Daha yeni, çok iş parçacıklı alternatifi s3cmd. Daha da umut verici görünüyordu, ancak yerel dosya sisteminde zaten mevcut olan dosyaları yeniden indirmeye devam ettiğini fark ettim. Bu, sync komutundan beklediğim türden bir davranış değildi. Uzak dosyanın yerel olarak zaten mevcut olup olmadığını kontrol etmeli (karma / dosya denetimi düzgün olacaktır) ve aynı hedef dizinde bir sonraki senkronizasyon çalışmasında onu atlamalıdır. Bu garip davranışı bildirmek için bir sorun ( bloomreach / s4cmd / # 46 ) açtım . Bu arada başka bir alternatif bulmaya başladım.

awscli
Ve sonra buldum awscli. Bu, Amazon'un S3 dahil farklı bulut hizmetleriyle etkileşim için resmi komut satırı arayüzüdür.

AWSCLI

Uzak kova dosyalarını yerel dosya sisteminize hızlı ve kolay bir şekilde indiren kullanışlı bir senkronizasyon komutu sağlar .

$ aws s3 sync s3: // paket-adınız / ev / ubuntu / s3 / paket-adınız /

Faydaları:

  • Ölçeklenebilir - büyük S3 kovalarını destekler
  • Çok iş parçacıklı - birden çok iş parçacığı kullanarak dosyaları daha hızlı senkronize eder
  • Akıllı - yalnızca yeni veya güncellenmiş dosyaları senkronize eder
  • Hızlı - çok iş parçacıklı yapısı ve akıllı senkronizasyon algoritması sayesinde

Yanlışlıkla Silme

Uygun bir şekilde, synckomut, kaynaktan (S3 demeti) eksikse hedef klasördeki (yerel dosya sistemi) dosyaları silmez ve bunun tersi de geçerlidir. Bu, S3'ü yedeklemek için mükemmeldir - dosyaların klasörden silinmesi durumunda, yeniden senkronize etmek onları yerel olarak silmez. Yerel bir dosyayı silerseniz, kaynak paketten de silinmez.

Ubuntu 14.04 LTS'de awscli kurulumu

Yükleyerek başlayalım awscli. Bunu yapmanın birkaç yolu var , ancak bunu yüklemenin en kolay yolunu buldum apt-get.

$ sudo apt-get install awscli

Yapılandırma

Sonra, yapılandırmak gerekir awscliEğer almak zorundadırlar bizim Erişim Anahtar Kimliği & Gizli Key ile IAM bir kullanıcı oluşturarak ve ekleyerek, AmazonS3ReadOnlyAccess politikasını. Bu aynı zamanda sizin veya bu kimlik bilgilerine erişim sağlayan herhangi birinin S3 dosyalarınızı silmesini de engeller. S3 bölgenizi, gibi girdiğinizden emin olun us-east-1.

$ aws yapılandır

aws configure

Hazırlık

Yerel S3 yedekleme dizinini, tercihen /home/ubuntu/s3/{BUCKET_NAME}. {BUCKET_NAME}Gerçek paket adınızla değiştirdiğinizden emin olun .

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

İlk Senkronizasyon

Devam edelim ve aşağıdaki komutla paketi ilk kez senkronize edelim:

$ aws s3 senkronizasyon s3: // {BUCKET_NAME} / ev / ubuntu / s3 / {BUCKET_NAME} /

Paketin var olduğunu varsayarak, AWS kimlik bilgilerinin ve bölgenin doğru olduğu ve hedef klasörün geçerli olduğu varsayılırsa, awsclitüm paketi yerel dosya sistemine indirmeye başlayacaktır.

Paketin boyutuna ve İnternet bağlantınıza bağlı olarak, birkaç saniyeden birkaç saate kadar sürebilir. Bu bittiğinde, paketin yerel kopyasını güncel tutmak için otomatik bir cron işi ayarlayacağız.

Bir Cron İşi Ayarlama

Devam edin ve şurada bir sync.shdosya oluşturun /home/ubuntu/s3:

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

Aşağıdaki kodu kopyalayıp şuraya yapıştırın sync.sh:

#! / bin / sh

# Geçerli tarih ve saati yankılayın

Eko '-----------------------------'
tarih
Eko '-----------------------------'
Eko ''

# Yankı betiği başlatma
echo 'Uzak S3 demeti senkronize ediliyor ...'

# Aslında senkronizasyon komutunu çalıştırın ({BUCKET_NAME} yerine S3 paket adınızı yazın)
/ usr / bin / aws s3 sync s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

# Echo komut dosyası tamamlama
echo 'Senkronizasyon tamamlandı'

Komut dosyası boyunca iki kez olmak üzere {BUCKET_NAME} kısmını S3 paket adınızla değiştirdiğinizden emin olun .

Pro ipucu: Sen kullanmalıdır /usr/bin/awsiçin bağlantısına awsolarak, ikili crontabsınırlı kabuk ortamında yürütür komutları ve kendi başına yürütülebilir bulmak mümkün olmayacaktır.

Ardından, chmodkomut dosyası tarafından yürütülebilmesi için emin olun crontab.

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

Gerçekten çalıştığından emin olmak için betiği çalıştırmayı deneyelim:

$ /home/ubuntu/s3/sync.sh

Çıktı şuna benzer olmalıdır:

sync.sh çıkışı

Ardından, crontabaşağıdaki komutu çalıştırarak mevcut kullanıcının bilgilerini düzenleyelim :

$ crontab -e

Bu ilk kez çalıştırıyorsanız crontab -e, tercih edilen bir düzenleyici seçmeniz gerekir. nanoYeni başlayanlar için birlikte çalışması en kolay olanı seçmenizi tavsiye ederim .

Senkronizasyon Frekansı

crontabBir komut yazarak betiğimizi ne sıklıkla çalıştıracağımızı ve betiğin yerel dosya sisteminde nerede bulunduğunu söylememiz gerekir . Bu komutun formatı aşağıdaki gibidir:

mh dom mon dow komutu

Aşağıdaki komut crontab, sync.shkomut dosyasını her saat çalıştıracak (dakika: 0 ve saat: * parametreleri ile belirtilir) ve komut dosyasının çıktısını dizinimizdeki bir sync.logdosyaya yönlendirmesini sağlayacak şekilde yapılandırır s3:

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

Bu satırı crontab, düzenlemekte olduğunuz dosyanın altına eklemelisiniz . Ardından devam edin ve Ctrl + W ve ardından Enter tuşlarına basarak dosyayı diske kaydedin . Daha sonra Ctrl + X tuşlarınanano basarak çıkabilirsiniz . şimdi senkronizasyon görevini her saat çalıştıracak.crontab

Uzman ipucu: Saatlik cron işinin başarıyla yürütüldüğünü inceleyerek /home/ubuntu/s3/sync.log, yürütme tarihi ve saati için içeriğini kontrol ederek ve hangi yeni dosyaların senkronize edildiğini görmek için günlükleri inceleyerek doğrulayabilirsiniz .

Her şey hazır! S3 demetiniz artık her saat otomatik olarak EC2 sunucunuzla senkronize edilecek ve gitmeniz iyi olur. Zamanla S3 klasörünüz büyüdükçe, yeni dosyaları barındırmak için EC2 sunucunuzun EBS birim boyutunu artırmanız gerekebileceğini unutmayın. Bu kılavuzu izleyerek her zaman EBS birim boyutunuzu artırabilirsiniz .


Blogunuza bir soru bıraktım, ancak meta verileri de senkronize etmenin bir yolu olup olmadığını merak ettim.
Devology Ltd

@Devology Ltd, Maalesef S3 nesne meta verileriyle çalışma şansım olmadı. Hızlı bir Google aramasından, bunu komutta awscliotomatik olarak senkronize etmeyi destekler gibi görünmüyor aws s3 sync. Görünüşe göre bunu manuel olarak uygulamanız gerekebilir.
Elad Nava

Teşekkürler @Ekad Nava - Durum olduğuna inandığım şeyi onayladığınız için teşekkür ederim.
Devology Ltd

1
Bu harika @EladNava paylaşım için teşekkürler, 2020'de hala geçerli!
kullanıcı1130176

İçinde milyonlarca dosya varken bu yanıt uymuyor. Dosya sistemindeki sınırlamalar nedeniyle çok pahalı, yavaş ve bazen imkansız hale gelir.
Psychozoic

30

S3'ün% 99,999999999 dayanıklılığa sahip olduğunu açıklayan ilgili bağlantıyı dikkate alarak, 1 numaralı endişenizi dikkate almayacağım. Ciddi anlamda.

Şimdi, 2 numara geçerli bir kullanım durumu ve sizin için gerçek bir endişe ise, kesinlikle 1 veya 3 numaralı seçeneklere bağlı kalırım. Hangisi? Gerçekten bazı sorulara bağlı:

  • Sürüm oluşturma özelliklerinden herhangi birine ihtiyacınız var mı yoksa bu yalnızca yanlışlıkla üzerine yazma / silme işlemlerini önlemek için mi?
  • Sürüm oluşturma ile uygulanan ekstra maliyet uygun mu?
  • Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. Bu senin için uygun mu?

Depolama kullanımınız çok büyük olmadıkça, kova sürümlemesine bağlı kalırım. Bu şekilde, verileri Glacier'a, diğer paketlere ve hatta başka herhangi bir sunucuya yedeklemek için fazladan bir koda / iş akışına ihtiyacınız olmayacak (bu gerçekten kötü bir seçimdir IMHO, lütfen unutun).


4
@SergeyAlekseev Glacier sizin için işe yarayacak bir şeyse, dosyalarınızı buzulda otomatik olarak arşivleyen bir kova üzerinde yaşam döngüsü kuralı ayarlamak çok hızlıdır. Yine de bir paket içinde (web kullanıcı arayüzünde) görünecekler ancak depolama sınıfı standarttan buzul olarak değişecektir. İşlenmiş dosyaları ana paketimden "tamamlanmış" bir pakete taşırım ve tamamlanan paketin üzerinde 1 günlükten daha eski her şeyi arşivleyen yaşam döngüsü kuralı bulunur. Bunlar, muhtemelen bir daha asla dokunmayacağım, ancak müşteri için saklamam gereken veri dosyaları.
Dan

28
% 99,9999999999'un depolamada / yedeklemede tam aws yığını olmak için yeterli bir neden olduğunu düşünmüyorum. Kalan% 0,0000000001'den bahsetmiyorum, ama daha çok beklenmedik bir şey olursa, tüm işinizin bir yerde yatması garip geliyor. Beklenmedik bir şekilde, ABD belirli bir ülkeye savaşa girebilir, Amazon tamamen hacklenir (cf. Sony), vb.
Augustin Riedinger

11
@AugustinRiedinger'ı bu konuda destekleyeceğim: "S3 sorunu" tanım gereği bilmediğiniz bir şey olabilir (ör. Hükümet sorunları) ve 99.99 gibi S3 SLA numaralarının dayandığı hipotezleri geçersiz kılabilir ... Verilerinizi yedekleme dahil uzun vadeli herhangi bir şey yaparken, çeşitlendirme iyi bir uygulamadır, eğer bir önkoşul olmamalıdır
lajarre

2
Puanlarınızın geçerli olduğuna kesinlikle katılıyorum. Ancak OP tarafından verilen seçeneklere (soruna AWS alternatifleri dahil hemen hemen tümü) dayanarak, "S3 sorununun" siz genişledikçe genişleyeceğini sanmıyorum. Yine de daha geniş düşünceleri görmek güzel.
Viccari

4
Eski cevap, ancak son (-ish) olaylardan bahsetmem gerektiğini hissediyorum. "Amazon'un web'i bozduğu gün", bir teknoloji yanlışlıkla S3 sunucularının büyük bir bölümünü sildi . Bu 24 saat içinde bile sorun erişilebilirlikti. Veri kaybı değil. Büyük miktarda sunucu kaldırılsa bile kesinlikle veri kaybı olmadı ve yine de
SLA'larına

14

S3 verilerinizi aşağıdaki yöntemleri kullanarak yedekleyebilirsiniz

  1. Yedekleme sürecini AWS datapipeline kullanarak planlayın, aşağıda belirtilen 2 şekilde yapılabilir:

    a. Bir s3 paketinden başka bir s3 paketine kopyalayabileceğiniz veri hattının copyActivity'sini kullanma.

    b. Özyinelemeli s3 klasörlerinin paketten diğerine (paralel olarak) yinelemeli kopyasını yapmak için veri hattı ShellActivity ve "S3distcp" komutlarını kullanma.

  2. Farklı veri sürümlerini korumak için S3 klasöründe sürüm belirlemeyi kullanın

  3. Verilerinizi yedeklemek için buzul kullanın (yedeklemeyi hızlı bir şekilde orijinal paketlere geri yüklemeniz gerekmediğinde kullanın (veriler sıkıştırılmış biçimde depolandığından buzuldan verileri geri almanız biraz zaman alır) veya kaydetmek istediğinizde yedeklemeden başka bir s3 kovası kullanmaktan kaçınarak biraz maliyet), bu seçenek, yedeklemek istediğiniz s3 kovasındaki yaşam döngüsü kuralı kullanılarak kolayca ayarlanabilir.

Seçenek 1 size daha fazla güvenlik sağlayabilir; örneğin, orijinal s3 paketinizi yanlışlıkla silmeniz durumunda ve başka bir avantaj, yedeklemenizi başka bir s3 paketindeki veri tabanlı klasörlerde depolayabilmenizdir; bu şekilde, belirli bir tarihte hangi verilere sahip olduğunuzu bilirsiniz ve belirli bir tarih yedeklemesini geri yükleyin. Her şey kullanım durumunuza bağlıdır.


@David: David'in aşağıdaki çözümünde önerdiği gibi, s3 paketini günlük veya haftalık olarak yedekleyen bir komut dosyası olabilir.Bu, ilk noktamla kolayca elde edilebilir (AWS veri hattı - bu size yedekleme sürecini günlük olarak planlama olanağı sağlar , haftalık vb.). Aws veri hattı üzerinde bir arama yapmanızı tavsiye ederim.
Varun

Bu, biraz umut vaat ediyor, çünkü buluttan en iyi şekilde yararlanma konusunda mükemmel olmayan modası geçmiş yaklaşımlara dayanmıyor (okuyun: crons). Data Pipeline ayrıca otomatik yeniden denemelere sahiptir ve yönetilen (sunucusuz) bir hizmettir.
Felipe Alvarez

13

Kolayca kullanılabilen Bölgeler Arası Çoğaltma özelliğini S3 paketlerinin kendisinde kullanmaya ne dersiniz ? İşte özellikle ilgili bazı yararlı makaleler


Ya bir bölgedeki bir dosyayı silerseniz, diğerinde kopyalanmamalıysa?
michelem

S3, silme işlemlerini kopyalamaz, şu bağlantıya bakın docs.aws.amazon.com/AmazonS3/latest/dev/… .
ᐅ devrimbaris

9

Şimdiye kadar bir fark bölgesinde bir çeşit artımlı yedeklemeyi tutmanın daha kolay bir yolu olacağını düşünürdünüz.

Yukarıdaki tüm öneriler gerçekten basit veya şık çözümler değildir. Buzulun bir seçenek olduğunu düşünmüyorum çünkü bunun bir arşiv çözümünden çok bir yedekleme çözümü olduğunu düşünüyorum. Yedeklemeyi düşündüğümde, yeni bir geliştiriciden felaket kurtarma işleminin yinelemeli olarak silindiğini veya uygulamanızda s3'ten bazı şeyleri silen bir istismar veya hatayı düşünüyorum.

Bana göre en iyi çözüm, bir kepçeyi başka bir bölgeye, birini günlük ve bir haftalık yedekleyen bir betiktir, böylece korkunç bir şey olursa, sadece bölgeleri değiştirebilirsiniz. Böyle bir kurulumum yok, sadece bunu yapmak için etrafta dolaşmadım çünkü bunu yapmak biraz çaba gerektirecekti, bu yüzden kullanmak için bir stok çözüm olmasını diliyorum.


Kabul. S3'te (hatta CRR - yerleşik çoğaltma) olağanüstü durum kurtarma için büyük boşluklar olması ilginçtir. Örneğin, bir paketi, dosya sürümü geçmişlerini, meta verileri (özellikle son değiştirilme tarihleri) vb. Hiçbir zaman geri yükleyemezsiniz. Şu anda mevcut olan tüm kurtarma senaryoları kısmi kurtarmalardır.
Paul Jowett

7

Bu soru bir süre önce yayınlanmış olsa da, diğer çözümlerle birlikte MFA silme korumasından bahsetmenin önemli olduğunu düşündüm . OP, verilerin kazara silinmesini çözmeye çalışıyor . Çok faktörlü kimlik doğrulama (MFA) burada iki farklı senaryoda kendini gösterir -

  1. Nesne sürümlerini kalıcı olarak silme - Paketin sürüm oluşturmasında MFA silmeyi etkinleştirin.

  2. Paketin yanlışlıkla silinmesi - MFA kimlik doğrulaması olmadan silmeyi reddeden bir paket politikası oluşturun.

İle çift çapraz bölge çoğaltma ve sürüm veri kaybı riskini azaltmak ve kurtarma senaryolarını geliştirmek.

İşte bu konuyla ilgili daha ayrıntılı bir blog yazısı .


0

Eğer, elimizde çok fazla veri var. Zaten bir paketiniz varsa, o zaman ilk seferde Senkronizasyon çok fazla zaman alacak, Benim durumumda 400 GB'ım vardı. İlk seferinde 3 saat sürdü. Bu yüzden replikayı S3 Bucket yedeklemesi için iyi bir çözüm haline getirebileceğimizi düşünüyorum.


Yaklaşık 7 TB'ları bir kovaya taşımak üzereyim ve en iyi seçeneği bulmaya çalışıyorum ... Senkronizasyondan daha iyi bir şeye ihtiyacım olduğunu düşünüyorum. Verileri buzulun GCS sürümüne kopyalamak için bir ardışık düzen kullanmanın en iyi genel güvenliği sağlayıp sağlamayacağını merak ediyorum.
Brendon Whateley

AWS DataSync burada bir seçenek olabilir.
Felipe Alvarez
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.