Comment choisir un service cloud pour les sauvegardes

Je songe à utiliser un service cloud pour sauvegarder l'un des sites Web de mon client.

Mes (clients) principales préoccupations sont (par ordre décroissant d'importance)

1. Protection de la propriété intellectuelle (secrets commerciaux, code source), détails du compte utilisateur, etc.
2. Garantie de disponibilité offerte par le fournisseur de services (pour minimiser les temps d'arrêt du serveur Web)
3. Coût
4. Vitesse de téléchargement / téléchargement

Idéalement, je souhaiterais un service qui ne soit pas lié de longue date (c'est-à-dire que je préférerais une sorte de service "à la carte")

Je voudrais également éviter le blocage des fournisseurs, où il est presque impossible de passer à un autre service.

Je voudrais des directives générales sur:

1. Comment choisir un fournisseur de services
2. Quels sont les principaux acteurs du domaine
3. recommandation de logiciel à utiliser pour: sauvegarde / restauration / et upload / download des fichiers sauvegardés / restaurés

Le logiciel serveur sera soit Ubuntu ou Debian (je posterai probablement une question sur le système d'exploitation à utiliser en tant que serveur - je connais déjà Ubuntu)

Toute solution qui n'inclut pas le chiffrement côté client avec des clés détenues par le propriétaire ne répondra pas à la première exigence énoncée (protection / sécurité IP) - tout piratage côté serveur révèle des données non chiffrées. Cela exclut les systèmes de synchronisation dans le cloud tels que Dropbox qui possèdent les clés.

Pour éviter d'héberger les clés de cryptage très importantes sur le serveur du site Web, qui est également susceptible d'être piraté à un moment donné, voici ce que je ferais:

1. Serveur de sauvegarde interne sur le site du client - possède des clés de chiffrement et des clés SSH pour les deux autres serveurs
2. Serveur hébergeant le site Web - pourrait être un hébergeur
3. Serveur ou service de sauvegarde cloud

Étape 1: le serveur (1) extrait la sauvegarde de (2), de sorte que la plupart des hacks du serveur du site Web ne compromettent pas les sauvegardes. Le cryptage a lieu à ce stade.

• J'utiliserais rsnapshot sur SSH en utilisant une connexion basée sur des clés, car cela a des exigences minimales sur l'hôte Web et le serveur de sauvegarde interne - à moins que vous n'ayez une grande base de données à sauvegarder, elle est très efficace en bande passante et stocke plusieurs versions du site, et gère également la purge des anciennes sauvegardes.
• Le chiffrement peut être effectué par n'importe quel outil de fichier à fichier tel que GPG, en copiant l'arborescence rsnapshot dans une autre arborescence - ou vous pouvez utiliser la duplicité pour l'étape 2, économiser de l'espace disque.
• "Extraire" du serveur de sauvegarde est important - si le serveur principal (2) possède les mots de passe / clés pour le serveur de sauvegarde, les pirates peuvent et parfois supprimeront les sauvegardes après avoir piraté le serveur principal (voir ci-dessous). Des hacks vraiment avancés peuvent installer des binaires SSH troyens qui pourraient alors compromettre le serveur de sauvegarde, mais c'est moins probable pour la plupart des entreprises.

Étape 2: le serveur (1) pousse les sauvegardes chiffrées vers (3) pour qu'il y ait une sauvegarde hors site. Si les sauvegardes ont été chiffrées à l'étape 1, vous pouvez simplement utiliser un miroir rsync de l'arborescence rsnapshot locale sur le système distant.

• La duplicité serait une bonne option pour crypter et sauvegarder directement l'arborescence rsnapshot non cryptée sur le serveur distant. Les fonctionnalités de Duplicity sont un peu différentes de rsnapshot, utilisant des archives tar chiffrées par GPG, mais il fournit un chiffrement de sauvegarde sur l'hôte distant et ne nécessite que SSH sur cet hôte (ou il peut utiliser Amazon S3). Duplicity ne prend pas en charge les liens durs , donc si cela est nécessaire (par exemple pour une sauvegarde complète du serveur), il est préférable qu'un script convertisse l'arborescence rsnapshot (qui prend en charge les liens durs) en un fichier tar (peut-être juste les fichiers qui ont> 1 lien dur, qui sera assez petit) pour que la duplicité puisse sauvegarder le fichier tar.
• Étant donné que le serveur distant n'est qu'un hôte SSH, éventuellement avec rsync, il peut s'agir d'un hôte Web (mais d'un fournisseur d'hébergement différent et dans une autre partie du pays), ou d'un service cloud qui fournit rsync et / ou SSH - voir cette réponse sur les sauvegardes rsync sur le cloud pour sa recommandation de bqbackup et rsync.net, bien que je ne sois pas d'accord avec la configuration de sauvegarde mentionnée.
• Vous pouvez utiliser Amazon S3 comme serveur distant avec duplicité, ce qui vous donnerait une très bonne disponibilité, mais cela coûterait peut-être plus cher pour les sauvegardes volumineuses.
• D'autres options pour les sauvegardes chiffrées à distance sont Boxbackup (pas aussi mature, quelques fonctionnalités intéressantes) et Tarsnap (service cloud commercial basé sur Amazon S3 avec une interface de ligne de commande simple, une bonne déduplication et un chiffrement très complet).
  • JungleDisk peut être une option mais je n'ai pas eu une grande expérience avec eux dans le passé et leur cryptage a quelques problèmes (de l'auteur de Tarsnap).

La sécurité de tous les différents hôtes est importante, elle doit donc être ajustée pour répondre au profil de sécurité du client, c'est-à-dire analyser les menaces, les risques, les vecteurs d'attaque, etc. Ubuntu Server n'est pas un mauvais départ car il a des mises à jour de sécurité fréquentes pour 5 ans, mais une attention particulière à la sécurité est requise sur tous les serveurs.

Cette configuration fournit 2 sauvegardes indépendantes, dont l'une peut être un service de stockage cloud hautement disponible, fonctionne en mode pull, de sorte que la plupart des attaques sur le site Web ne peuvent pas détruire les sauvegardes en même temps et utilise des outils open source éprouvés qui ne le font pas. nécessitent beaucoup d'administration.

• Les sauvegardes indépendantes sont essentielles, car les pirates suppriment parfois toutes les sauvegardes en même temps que le piratage du site Web - dans le cas le plus récent, les pirates ont détruit 4800 sites Web, y compris les sauvegardes en piratant l'environnement d'hébergement Web plutôt que les sites. Voir aussi cette réponse et celle-ci .
• La restauration est très facile avec rsnapshot - il y a un fichier dans chaque arborescence de snapshots pour chaque fichier sauvegardé, alors il suffit de trouver les fichiers avec les outils Linux et rsync ou de les recopier sur le site Web. Si le serveur de sauvegarde sur site n'est pas disponible pour une raison quelconque, utilisez simplement la duplicité pour les restaurer à partir du serveur de sauvegarde cloud - ou vous pouvez utiliser des outils standard tels que GPG, rdiff et tar pour restaurer les sauvegardes.

Étant donné que cette configuration utilise SSH et rsync standard, il devrait être plus facile de choisir un fournisseur approprié avec les bonnes garanties de disponibilité, une sécurité renforcée, etc. Vous n'avez pas besoin de vous connecter à un contrat long et si le service de sauvegarde a une catastrophe En cas d'échec, vous disposez toujours d'une sauvegarde locale et pouvez basculer vers un autre service de sauvegarde assez facilement.

Du point de vue logiciel, envisagez la duplicité pour les sauvegardes incrémentielles avec chiffrement asymétrique et un récepteur stupide ( howto non cloud ).

Je dis toujours à mes clients que la solution de sauvegarde la meilleure, la moins chère et la plus efficace est celle que vous créez vous-même, pour vos propres besoins.

Lorsque je crée un système pour mes clients, j'utilise rsync avec des clés SSH pour gérer l'authentification entre serverA et serverB, où serverA contient les données à sauvegarder. La commande pour archiver et rsync les données est contenue dans un script bash dans un répertoire non accessible sur le Web, appelé par cron toutes les H heures (24 pour tous les jours, etc. etc.)

Le serveur de sauvegarde, serverB, doit être utilisé UNIQUEMENT pour les sauvegardes. Je conseille toujours à mes clients d'utiliser un mot de passe extrêmement long avec authentification par clé SSH pour permettre le téléchargement des sauvegardes et la sauvegarde. Parfois, mes clients ont besoin que les sauvegardes soient enregistrées pendant D jours, alors j'écris quelques scripts pour gérer cela (prendre des données du répertoire de sauvegarde actif, appliquer un horodatage, ajouter à une archive dans un autre répertoire).

Pour les petites entreprises / prosommateurs, je recommanderais le service de stockage d'Amazon .

• Contrôle de région (c'est-à-dire que les objets stockés dans une UE ne quittent jamais l'UE).
• Disponibilité de 99,9% pour tout cycle de facturation donné
• 0,150 $ par Go stocké par mois
• 0,170 $ par Go téléchargé
• Téléchargement gratuit jusqu'en juin 2010, 0,10 $ par Go par la suite

Et l'assurance plutôt vague que "des mécanismes d'authentification sont fournis pour garantir que les données sont protégées contre tout accès non autorisé"

Alors que bluenovember est sur la bonne voie avec S3, le système d'Amazon n'est pas vraiment une solution de sauvegarde intégrée, c'est une solution de stockage de données brutes qui nécessite toujours un système frontal pour la sauvegarde, que ce soit quelques appels d'API ou un suite de gestion de sauvegarde complète. Quelque chose comme JungleDisk Server Edition , qui utilise S3 à l'arrière-plan mais fournit une meilleure interface pour une utilisation comme solution de sauvegarde, serait probablement mieux.

De plus, JungleDisk vous offrirait un cryptage intégré, quelque chose que vous auriez besoin d'ajouter, quelle que soit la façon dont vous prévoyez de vous connecter à S3 / «le cloud». Ils ont également un logiciel client assez agréable pour Linux.

J'aime stocker ma sauvegarde dans Amazon AWS et j'utilise l'outil gratuit s3cmd ( http://s3tools.org/s3cmd )

Il peut être installé assez facilement (Debian: apt-get install s3cmd).

Tout ce dont vous avez besoin d'un compte Amazon AWS pour stocker vos fichiers sur S3. Ensuite, une simple commande peut exécuter votre sauvegarde, même incrémentielle ou comme solution de synchronisation, par exemple:

s3cmd sync /srv/backup  s3://your-bucket-name-at-amazon/

Assurez-vous de courir

s3cms --configure 

d'abord pour entrer vos informations d'identification AWS.