Ai-je encore besoin d'une sauvegarde si j'ai un système de stockage redudant avec des fonctions de restauration?

Mon organisation a récemment acheté un système de stockage. Il a 1,5Petabyte, avec RAID6, et il y a un miroir synchronisé en ligne dans un emplacement physique différent.

Le système permet la restauration / restauration de fichier, autorisant par défaut jusqu’à 30 jours, mais ce délai peut être augmenté.

Une discussion est en cours si nous avons besoin d'une sorte de sauvegarde supplémentaire pour les données stockées uniquement sur le stockage.

Le système a un très bon niveau de redondance, une redondance géographique et permet jusqu’à un certain point d’annuler, ce qui signifie que nous pouvons récupérer jusqu’à la période définie (30 jours par défaut) des données anciennes ou des données supprimées accidentellement.

Compte tenu de ce scénario, est-il toujours utile de disposer d’une sauvegarde "traditionnelle"? Par tradition, j'entends un système de sauvegarde dédié, avec des instantanés que nous pouvons récupérer en cas de problème.

En avons-nous vraiment besoin? Est-ce que je manque quelque chose? Suis-je simplement en train de penser de manière traditionnelle et d’être trop zélé?

Ce que vous décrivez est essentiel: un RAID réparti géographiquement et un RAID n’a jamais été une sauvegarde .

La synchronisation en ligne signifie généralement que tout ce que vous faites sur le stockage principal est immédiatement répliqué sur le système de sauvegarde, y compris des opérations telles que la suppression de tous les instantanés et / ou de volumes par un attaquant ou simplement une erreur administrative.

La restauration de 30 jours est une excellente possibilité, mais que se passe-t-il si "critically-important-file-xyz" est corrompu / endommagé et si cela n'est détecté que 31 jours plus tard? Cette situation est la différence entre les calendriers de sauvegarde et d'archivage, mais dans votre description, ce dernier n'est pas mentionné. Les systèmes d’archivage sont généralement stockés sur des bandes à très faible coût. En outre, aucune information n'est disponible sur le fait que l'entreprise soit soumise à des obligations réglementaires ou autres en matière de conservation des données pendant plus de 30 jours, ce qui est souvent le cas.

Si ce n'est pas le cas pour votre situation, alors vous devriez être bon.

Avoir des machines séparées géographiquement les deux ayant les données est bon.

Que se passe-t-il lorsque vous avez plusieurs échecs impliquant vos deux sites ou tous vos sites? Un incendie sur l'un, le vol des serveurs sur l'autre? Ou il y a un problème avec la ligne entre eux, puis le serveur de l'emplacement principal s'éteint, et le contrôleur HD devient singe et écrit des bric-à-brac? Ou un initié effectue des actes malveillants sur les deux? Ou le FBI confisque vos serveurs sur les deux sites en raison de soupçons (vous ne le feriez jamais, mais vous êtes peut-être co-hébergés dans un centre de données avec schmucks). Ou .. Je me souviens de plusieurs pannes de haut niveau dans le «cloud», où tout était redondant, analysé au nième degré, mais où, malgré tout, les choses peuvent mal se passer. Je vous concède que tout cela est improbable, mais vous avez reconnu que des événements improbables peuvent se produire.

Il s’agit donc de l’importance / de la valeur de ces données. Que fera l'organisation si elle finit par disparaître?

La question ici semble être de savoir à quel point une copie répliquée de vos données doit être déconnectée et distincte géographiquement avant de devenir une infrastructure de sauvegarde et non une infrastructure à haute disponibilité / redondance. Mon instinct, c'est que tu es proche, mais que tu as toujours besoin d'une sauvegarde.

Pour rassembler certaines idées dans les autres réponses et commentaires, vous pouvez aller très loin dans la voie suivante: "Bien, la technologie X ne couvre pas le scénario catastrophe de Y, ce n'est donc pas une sauvegarde", et à un moment donné. vous devez décider ce qui est raisonnable pour vous, ce qui semble être la raison pour laquelle vous demandez. Mon opinion à ce sujet, et celle de nombreux commentateurs, est que votre sauvegarde doit exister sur une infrastructure technologique distincte de vos données en cours d'utilisation afin que les échecs, les accidents et les actions malveillantes ne puissent pas se propager ou aient lieu. un obstacle beaucoup plus difficile à franchir. Un exemple donné dans les commentaires est une personne qui supprime les volumes, ce qui, à mon avis, est un scénario valide, mais pas du ciel. Mais aussi, un exemple du monde réel tiré de mon travail. L’université pour laquelle je travaille (mais heureusement, ne le faites pas) t gérer cette infrastructure pour) possède une infrastructure de virtualisation à haute disponibilité sérieuse qui prend en charge une grande partie des installations du campus. Il se trouve sur plusieurs sites, mais fonctionne tous sur la plate-forme d'un fournisseur. Un bogue obscur est apparu un jour, ce qui a provoqué une cascade d’échecs qui a d’abord détruit un seul serveur, puis, lorsque la charge a été déplacée, le reste de ce site a été supprimé. cette infrastructure. (Je crois qu'ils ont résolu ce problème depuis lors). Les données n'ont pas été perdues dans ce cas, mais il est possible d'imaginer un scénario impliquant vos données là où elles se trouvaient. Un bogue obscur est apparu un jour, ce qui a provoqué une cascade d’échecs qui a d’abord détruit un seul serveur, puis, lorsque la charge a été déplacée, le reste de ce site a été supprimé. cette infrastructure. (Je crois qu'ils ont résolu ce problème depuis lors). Les données n'ont pas été perdues dans ce cas, mais il est possible d'imaginer un scénario impliquant vos données là où elles se trouvaient. Un bogue obscur est apparu un jour, ce qui a provoqué une cascade d’échecs qui a d’abord détruit un seul serveur, puis, lorsque la charge a été déplacée, le reste de ce site a été supprimé. cette infrastructure. (Je crois qu'ils ont résolu ce problème depuis lors). Les données n'ont pas été perdues dans ce cas, mais il est possible d'imaginer un scénario impliquant vos données là où elles se trouvaient.

Vous voulez que votre sauvegarde soit à l'abri de tout cela, et même accessible lorsque l'infrastructure est en panne. Si les données sont indisponibles pendant une semaine pendant la reconstruction de votre RAID, il est agréable de pouvoir récupérer des documents stratégiques à partir d’une sauvegarde. Si votre RAID disparaît, puis se réplique sur votre autre site, vous souhaiterez vraiment que cette sauvegarde provienne d'un fournisseur distinct ou d'un support isolé, tel qu'une bande.

Tout cela étant dit, je vous répète que votre sauvegarde doit se trouver sur une infrastructure distincte de vos données. Il existe de nombreux niveaux d'isolation ici, mais je pense que tout ce qui est connecté via la réplication directe est trop proche pour être une sauvegarde. Vous voudrez quelque chose en plus.

Hypothèse: le système de stockage sera utilisé par de nombreuses applications.

Je pense que vous ferez beaucoup mieux avec un système de sauvegarde séparé.

Le RAID et la mise en miroir ne sont pas des sauvegardes, mais la fonctionnalité de restauration intégrée peut remplacer un système de sauvegarde traditionnel.

MAIS:

Je préfère que les politiques de récupération soient basées sur les applications / données et non sur le stockage, car:

1. les applications ont des exigences différentes en matière de récupération et de perte de données acceptable (certaines d'entre elles étant imposées par diverses réglementations: supports en lecture seule, cryptage, conservation des X dernières années, etc.),
2. certaines applications ont (très) de bons outils de sauvegarde et de récupération (oracle, mssql) intégrés et sont des moyens recommandés pour effectuer la partie sauvegarde / récupération (en tant que DBA Oracle, je préfère et je ferai toutes mes sauvegardes liées à Oracle avec rman).
3. croissance, votre utilisation de l’espace peut croître beaucoup plus rapidement que ce à quoi vous vous attendiez. Ce système peut désormais gérer 30 jours de données de restauration, ce qui n’est plus garanti à l’avenir.
4. moins onéreux, le coût d’utilisation de bandes plus volumineuses pour les politiques de sauvegarde / restauration, après plusieurs années de croissance, sera inférieur au coût d’achat de nouveaux disques plus volumineux afin de respecter la même fenêtre de restauration que celle d’aujourd’hui