Strategia di backup Amazon EC2

Ho un paio di configurazioni di server Web / DB che utilizzano Amazon EC2. Attualmente sto prendendo istantanee quotidiane di tutto il mio sistema e le unità EBS che contiene tutti i miei file dell'applicazione, file DB, codice sorgente e backup DB. Ho un'applicazione console che esegue le creazioni di backup secondo una pianificazione. Le mie immagini sono immagini EBS.

Sto lavorando a un'attività che lascerà cadere le mie istantanee dopo tanti giorni. Immagino che la mia domanda sia: dovrei / posso anche pianificare un'attività completa di immagine / EBS? In questo modo, se il server si guasta o è danneggiato, posso solo lanciare l'immagine più recente e quindi applicare l'ultima istantanea.

Mentre sto lavorando sulla mia strategia di backup, sto usando Jungle Disc per eseguire il backup dei miei dischi di dati.

I miei consigli:

1. Documentare e / o scriptare sempre l'installazione di ogni nuova istanza in modo da poter riprodurre l'installazione del software e la configurazione del sistema in caso di perdita dell'istanza. Prova questo avviando una nuova istanza e seguendo la procedura. È possibile utilizzare un'AMI privata personalizzata se l'installazione richiede molto tempo e è necessario avviare rapidamente le istanze, ma tale AMI stessa deve essere creata utilizzando una procedura documentata e / o gestita da script.

2. Conservare i dati importanti su volumi EBS separati e non sul volume EBS radice. Ciò comporta numerosi vantaggi, tra cui la semplificazione del trasferimento dei dati in nuove istanze (ad esempio, basato su diverse AMI) e la semplificazione dell'ottenimento di copie dei dati in altre istanze (ad esempio, con istantanee e nuovi volumi).

3. Creare istantanee regolari dei volumi di dati EBS. Se possibile / applicabile, utilizzare uno strumento come il mio ec2-coerente-istantanea per migliorare le possibilità che si stia acquisendo un'istantanea di un file system / database coerente. Eseguire il backup dei dati all'esterno di AWS / EC2, poiché l'account AWS stesso rappresenta un singolo punto di errore.

4. Creare istantanee del volume EBS di root di volta in volta su istanze importanti. Anche se questo può aiutarti in caso di errore del volume dell'istanza o EBS, quella parte non è così critica a causa del n. 1 e n. 2 sopra. Il motivo principale per cui lo faccio è che la creazione di snapshot riduce il rischio di errore del volume EBS radice stesso.

Il tasso di errore di un volume EBS è direttamente correlato al numero di blocchi che sono stati modificati su quel volume dall'ultima istantanea EBS.

Devo / posso anche pianificare un'attività completa di immagine / EBS?

si, è consigliabile. Una volta mi ha salvato, perché ho dovuto ripristinare molte volte a causa di problemi del kernel, fino a quando il disco di avvio non era più leggibile e ho semplicemente avviato dall'ultima istantanea.

Se sei interessato, ho scritto una classe Java per creare un'istantanea di tutti i volumi EBS collegati e anche eliminarli dopo un certo periodo di tempo. Attualmente eseguo un backup ogni settimana e scarto il terzo backup dopo due settimane.

https://github.com/stivlo/obliquid-cp/blob/master/src/main/java/org/obliquid/sherd/runner/RequestSnapshots.java

Esegue solo un'azione per esecuzione, come eseguire o eliminare uno snapshot, perché è pensato per essere inserito in un cron ogni ora per evitare di sovraccaricare con decine di snapshot allo stesso tempo nel caso in cui tu abbia molte EBS come me.

Utilizziamo una strategia di backup semplice ma potente: creiamo nuove AMI sulla base dell'esecuzione di istanze EBS EC2 due volte al giorno ed eliminiamo le AMI "vecchie". Tramite l'API (CreateImage) puoi impostare flag non riavviare l'istanza durante la creazione di una nuova AMI o, se usi il raid del software - ssh all'istanza prima di creare l'API CreateIImage e bloccare il filesystem con "fsfreeze" sui filesystem più popolari sui nuovi kernel o xfs_freeze se usi kernel e xfs precedenti.

L'AMI di "backup" creato ricorda tutti i dischi EBS dell'istanza in esecuzione originali (tramite collegamenti a istantanee create) e, nel caso di utilizzo di raid software con più dischi, consente di ripristinare una nuova istanza in qualsiasi AZ semplicemente con una chiamata API o tramite web -interfaccia.