stratégie de sauvegarde rationnelle pour les applications Web

Question

Je fais une webapp et j'ai besoin d'un plan de sauvegarde. Voici ce que j'ai jusqu'à présent:

• sauvegarde nocturne chiffrée de la base de données SQL sur Amazon S3 et mon lecteur externe (incrémentielle si possible, pas encore trop familiarisée avec PostgreSQL, mais c'est un autre thread)
• sauvegarde nocturne de mon référentiel Mercurial (comprenant la configuration Apache, les scripts de déploiement, etc.) sur S3 (sauvegardes locales via Time Machine)

Dois-je ajouter quelque chose, ou est-ce que cela va couvrir? Pour vous donner une idée de la gravité des données, c’est une application de gestion de projet inspirée de Basecamp.

Answer 1

Une sauvegarde complète hebdomadaire de votre base de données ainsi que des sauvegardes incrémentielles nocturnes peut-être aussi?

Cela signifie que si l'une de vos anciennes sauvegardes incrémentielles est corrompue, vous avez perdu moins d'une semaine de données.

Assurez-vous également que vous disposez d'un plan de test de sauvegarde pour vous assurer que vos sauvegardes fonctionnent. Il y a beaucoup d'histoires d'horreur qui circulent à ce sujet, d'entreprises qui font des sauvegardes depuis des années, ne les testent jamais et découvrent qu'aucune d'entre elles n'est vraiment utile une fois qu'elles en ont besoin. (Je suis aussi allé dans une entreprise comme celle-ci. Heureusement, j’ai remarqué que les sauvegardes ne fonctionnaient pas avant qu’elles ne soient nécessaires et que les problèmes aient été résolus.)

Answer 2

L’une des meilleures stratégies qui a fonctionné pour moi par le passé a été d’avoir la "sauvegarde". processus soit identique au processus d’installation, c’est-à-dire que nous avons entièrement écrit dans Linux la configuration du serveur, la création de l’application, la configuration de la base de données, etc., de sorte que l’installation ressemble à ceci:

./ install.sh [serveur] [nom de l'application] et la sauvegarde / récupération ./install [serveur] [nom de l'application] -database [fichier de sauvegarde de la base de données]

En termes de sauvegarde, la base de données a été entièrement sauvegardée (base de données MySQL), par un cronjob

Cela garantissait à peu près que la récupération était testée chaque fois qu'une nouvelle instance était déployée, et que les scripts étaient également utilisés pour déplacer des instances lorsque le matériel devait être remplacé ou qu'un serveur donné était surchargé par un client. .

C’était la configuration d’une application d’entreprise Saas avec laquelle j’avais travaillé il ya quelques années. Nous avions donc le plein contrôle des serveurs.

Answer 3

Je le ferais si vous pouviez passer d’une sauvegarde incrémentielle à une différentielle. Si vous avez une sauvegarde incrémentielle, vous devez appliquer la sauvegarde complète hebdomadaire, puis toutes les sauvegardes suivantes. Si l'une de vos sauvegardes incrémentielles échoue au début de la semaine, toutes vos sauvegardes ultérieures échoueront également.

Toutefois, si vous utilisez un différentiel, chaque différentiel contient toutes les modifications depuis la dernière sauvegarde. Par conséquent, même si l’une des sauvegardes échouait plus tôt dans la semaine, vous pourrez toujours effectuer une récupération complète si la sauvegarde est réussie.

J'espère bien expliquer cela!

: