Every, or almost every, system engineer – provided they have a few years of experience – once heard an intern or a new joiner speak their astonishment that the infrastructure teams performs data backups or asks the business people for the backup policy of a business application.
Making backups? That's paleo-computing, a boomer thing! On magnetic tapes, no less? The data is stored in the Cloud or on a RAID disk anyway!
Mistaken you are, young padawan... So mistaken !
Data are the most precious asset of an enterprise
... after its human resources (but, is it respectful to qualify human resources as just "assets" ?)
Enterprises, or organizations, very seldom and very hardly recover from the complete and definitive loss of their data.
Try and imagine what the mayhem a company would find itself in if, all of sudden, it no longer knew what the status of its stocks was, nor what the progress of its projects was, nor who its employees were, nor which suppliers had already been paid, nor which invoices its customers had not yet or had already paid, etc. etc. It would take a colossal amount of energy and an impressive number of weeks, even months, for this company to recover from such a shock and be able to resume normal, or even just quasi-normal, activity.
Try and imagine the financial loss constituted by the sudden disappearance of hundreds, thousands, of work hours of many employees who had produced and treated the data that were deleted or corrupted during an incident.
A company which doesn't take enough care of its data cannot be resilient.
Such a company puts its business at risk, at serious risk.
There are many risks to data
Wherever a company or an organization keeps its data, many risks are threaten these data.
Whether it is the accounting of an association, recorded in an Excel® file stored on the hard drive of the association's only computer; whether it is the Java or Python code of the latest software being developed in a 200 employees company; whether it is the HR/payroll database of a 2000 people company... all of this data is under constant threat in terms of its availability, confidentiality and integrity.
And it's not just activist hackers in the pay of dictatorial regimes or mercenaries in the service of discreet mafias who threaten this data. A flood or fire in the company's premises, a handling error by a person of good faith, a coffee accidentally spilled on the sports team laptop, a rather violent vacuum cleaner bump in the shared hard drive of the architect's studio...
Each and every risk must meet its solution, aligned with what is at stake and with the available budget.
Redundant storage protects, but from what?
Local redundancy - RAID
In general, what is called redundant storage is the set of RAID technologies that consists of grouping and assembling several physical hard disks and combining them into a single logical hard disk. The logical disk, or "RAID volume", is the one that the system uses and on which the data is stored and processed.
Each write on the RAID volume will be reflected on all the physical disks that make up the volume. This redundant distribution of data is carried out according to an algorithm characteristic of the chosen RAID level. Thus, if one of the physical disks ever fails, the data present on the other physical disks allows on the one hand to serve on-the-fly all the data of the volume and on the other hand to reconstruct the contents of the lost disk.
The replacement of the failed physical disk and the reconstruction of its content from the healthy physical disks within the RAID volume will restore the reliability level of the volume. Depending on the RAID technology implemented, the performance of the RAID volume generally remains degraded until the reconstruction of the failed physical disk's content is completed on the replacement disk.
As there are several RAID algorithms for combining hard drives, each has its own characteristics, advantages, disadvantages, costs... and therefore its typical uses.
Redundant storage is therefore tolerant to failures (of hard disks). The practical implementation of RAID can be carried out by the software or by the hardware:
- In the first case, it is the operating system that spends a little computing power to apply the RAID algorithm to the physical disks that are connected to the machine,
- Dans le second cas, une carte RAID physique est installées dans la machine et c'est l'électronique embarquée sur cette carte qui fait tout le travail d'assemblage et de gestion des disques physiques qui sont connectés à la carte. Le système d'exploitation ne voit lui que le ou les volume(s) RAID résultant(s).
Donc oui, le stockage redondant protège effectivement les données stockées, mais uniquement contre un crash de disque dur.
Geo redundancy - Replication
Companies of a certain size, or responding to certain important challenges, may be led to consider using several geographical sites, more or less distant from each other, to host their data and their IT production.
Manufacturers of centralized/shared storage system, such as SAN arrays or NAS, almost all offer storage replication functions from one system to another. This provides additional redundancy, this time at the geographical level.
Not only is data on a site protected against the hardware failure of physical disks, it is also protected against a failure that would affect the centralized/shared storage system of a site, or even the whole site.
Limitations
Quand un fichier stocké sur un disque combiné en RAID est supprimé ou réécrit, le fichier est supprimé/réécrit sur tous les disques qui composent le RAID.
Again, deletion or rewriting of a file content on one site will be propagated on all replicated sites.
Data replication between two centralized/shared storage systems has its own limitations, particularly those arising from the finiteness of light and electricity propagation speeds, which therefore impact the time required to replicate data from one site to another.
Backups protect, differently
Backing up data consist of making a copy of this data at a given time T from its "usual" medium to a medium dedicated to backup.
The goal of the backup is to be able to return to this given time T :
- In case the data was deleted at T + 2 hours or at T + 2 days, the backup is restored and the data at time T is recovered,
- In case the data was modofied (or corrupted) at T + 3 hours or T + 3 months and the state of data at time T is needed, the backup is restored,
- In case the data was lost at T + 1 hour or T + 1 week because of a disaster at the location where the data was stored, the backup is restored (potentially on a different site).
Évidement, quand dès qu'on a quelques gigaoctets de données à protéger il va falloir tenir un journal des sauvegardes qui sont réalisées. Il est en effet capital de savoir précisément d'où viennent les données sauvegardées et quand elles ont été sauvegardées. C'est le rôle de l'outil de sauvegarde. Il en existe plusieurs, certains Open Source, chacun ayant sa propre philosophie, ses avantages, ses inconvénients, ses coûts.
Backup policy
The backup policy includes determining for each data set the answers to a few basic questions:
- Dans tout l'ensemble qui constitue la donnée, il faut déterminer explicitement ce qui a vraiment de la valeur,
- La donnée que l'o, s'apprête à sauvegarder est-elle une donnée de première main (golden source) ou bien n'est-elle que la duplication d'une donnée déjà sauvegardée à la source ?
- existe-t-il des contraintes légales ou règlementaires qui imposent de sauvegarder certaines informations,
- avec la donnée faut-il également sauvegarder les informations relatives aux traitements, faut-il sauvegarder les logiciels qui permettent ces traitements,
à quel moment de la journée, de la semaine, du cycle de traitement(s) de la donnée...
- faut-il s'assurer que la donnée est logiquement/fonctionnellement cohérente avant de la sauvegarder,
- doit-on copier directement des fichiers du disques durs vers le support de sauvegarde, faut-il d'abord exporter les données puis copier ces exports,
- si l'opération de sauvegarde limite les traitements sur les données, de combien de temps dispose-t-on pour sauvegarder la données,
- existe-t-il des contraintes légales ou règlementaires qui imposent de chiffrer ou d'anonymiser une partie des données,
- Sauvegarder la donnée va créer une nouvelle copie (au moins une), en termes de confidentialité ce n'est pas anodin.
- Les opérations de sauvegardes peuvent avoir un impact sur la performance d'accès ou de traitement des données.
- existe-t-il des contraintes légales ou règlementaires qui imposent (ou interdisent) de copier les données sur un type de support en particulier,
- quels support est le plus adapté aux caractéristiques de la données et à ses contraintes,
- Quels support permettra le plus facilement de purger les sauvegardes en cas d'obligation ?
- Existe-t-il des contraintes légales ou règlementaires qui imposent d'éloigner géographiquement les copies de sauvegarde par rapport à la donnée initiale ?
- existe-t-il des contraintes légales ou règlementaires qui imposent de conserver les données pendant une durée minimale (obligation de rétention),
- existe-t-il des contraintes légales ou règlementaires qui interdisent de conserver les données au-delà d'une durée maximale (obligation de purge/suppression, droit à l'oubli),
- que faut-il faire des sauvegardes précédentes quand la donnée est à nouveau sauvegardée après une modification,
- Que faut-il faire des sauvegardes précédentes quand la donnée a été supprimée à son emplacement d'origine ?
- Existe-t-il des obligations légales ou règlementaires qui imposent de signer numériquement les sauvegardes pour garantir leur immutabilité ?
- Combien de copies de sauvegarde faut-il générer ?
- Quand la donnée évolue rapidement, quelle "fraîcheur" de la donnée est-on autorisé à sacrifier ?
- De quels événements veut-on protéger la donnée ?
- Faut-il envisager la destruction totale du site où se trouve initialement la donnée ?
- En combien de temps faudra-t-il recouvrer l'accès à la donnée perdue/détruite ?
Il faut se poser ces questions pour chaque ensemble de données, pour chaque application métier.
On notera que la loi française dites "Informatique et Libertés" et le règlement européen dit RGPD vont notamment compter dans les réponses à la question "COMBIEN de TEMPS".
Une très grande partie des réponses ne peut être fournie que par le propriétaire des données.
En effet, par exemple, pour des données comptables, seule l'équipe comptabilité pourra répondre aux questions "QUAND" et "COMBIEN DE TEMPS".
En marge de la politique de sauvegarde à proprement parler, il faut aussi traiter avec soin le cycle de vie des sauvegardes :
- D'une part, il faut anticiper l'obsolescence du matériel et du logiciel qui servent à réaliser les sauvegardes, à en garder la trace et à procéder aux restaurations,
- D'autre part, il faut impérativement vérifier régulièrement l'état des copies de sauvegardes et de leurs supports. En effet, certains supports sont sujets à dégradation au cours du temps, lorsque les supports sont amovibles l'inventaire et la localisation doivent être précis, et les supports peuvent eux-mêmes être sujets à obsolescence,
- Enfin, quand une copie de sauvegarde expire à la fin de la durée de rétention des données, il faut procéder à sa destruction de manière controlée: vérifier que l'obligation de purge est bien respectée et que le support de sauvegarde ne garde pas de traces des données qui pourraient être exploitées (par une personne malveillante notamment)
Certains logiciels de sauvegarde procèdent d'eux-mêmes à la relecture des copies de sauvegarde pour "compacter" les données sur les supports. En effet, les données sur un même support n'ont pas forcément la même durée de rétention. Et ces logiciels peuvent utiliser les copies multiples des sauvegardes pour régénérer les supports qui auraient été altérés ou perdus.
La question du budget dont on dispose est évidemment cruciale, elle conditionne ce qui est réellement faisable et donc le niveau de qualité des pratiques de sauvegarde par rapport aux ambitions posées par la politique de sauvegarde.
Les limitations ou restrictions de budget ne sont en aucun cas une justification acceptable pour une absence de politique de sauvegarde. Il n'y a aucune justification possible à l'absence d'une politique de sauvegarde. Même minimaliste, la politique de sauvegarde doit exister !
La règle 3 - 2 - 1 des sauvegardes
Cette règle synthétique est une bonne pratique que les ingénieur·e·s spécialistes des sauvegardes utilisent pour vérifier que la politique et les pratiques de sauvegarde permettront de restaurer les données le moment venu.
En plus de la donnée initiale, celle qui sert "vraiment" (la production), il faut (au moins) deux copies de sauvegarde, donc un total de trois copies.
La donnée initiale est en général sur un disque dur, il faut que les copies de sauvegardes se trouvent chacune sur un support physiquement différent, et même mieux : technologiquement différents et géographiquement distinct.
Au moins une des copies de sauvegarde doit se trouver dans un site géographique distinct et distant de la donnée initiale, idéalement cette copie est également "hors ligne".
Avoir une des copies de sauvegarde "hors ligne" consiste à faire en sorte que cette copie ne puisse pas être manipulée sans une intervention physique humaine. Par exemple, pour sortir une bande/cassette du coffre-fort et la remettre dans une bibliothèque automatisée. Ainsi, il n'est pas possible à une personne malintentionnée, ou a une défaillance du logiciel de sauvegarde, d'effacer cette copie de sauvegarde par des moyens électroniques/informatiques.
Restoration
Une politique de sauvegarde doit être accompagnée de ce qu'on pourrait appeler une "politique de restauration".
Tout d'abord, cette politique de restauration doit définir le cadre dans lequel les restaurations sont réalisées. C'est-à-dire par quel processus le besoin de restauration est exprimé, sa légitimité est vérifiée, qui prend en charge les opérations de restauration, comment sont-elles conduites et dans quelles conditions leur résultat est mis à disposition du demandeur.
Toutes sortes de problèmes peuvent empêcher d'utiliser les données sauvegardées pour les restaurer ou tout simplement pour les utiliser correctement une fois restaurées : politique de sauvegarde inadaptée (mauvaises réponses aux QUOI, QUAND, COMMENT notamment), copies de sauvegardes manquantes ou corrompues, ...
Il est donc crucial de tester régulièrement et fréquemment la restauration des sauvegardes en procédant à des tests de restauration. Évidemment, il s'agit ici de restaurer les copies de sauvegarde sur une plateforme de tests distincte de la plateforme initialement sauvegardée. La plateforme de test de restauration doit être en mesure de vérifier que les applications, traitements et processus qui utilisent les données restaurées démarrent et fonctionnent comme attendu, c'est-à-dire au moins aussi bien qu'en production (aux écarts de perfomances près si le matériel est différent).
La fréquence des tests de restauration doit être adaptée à la criticité des données, et des processus/traitements métier qui les utilisent, pour l'organisation. Plus une application est critique pour la vie d'une entreprise plus il faudra procéder souvent aux tests de restauration.
Now, what about cloud storage ?
Chaque solution de stockage cloud a ses propres caractéristiques en matière de protection contre la perte de données. Il est donc capital de vérifier que ces caractéristiques sont adaptées aux impératifs de protection qui pèsent sur les données.
Redundancy
Cloud services providers all, or nearly all, propose redundant storage and so data will be protected against hardware failures. That's obviously the least you can expect from a cloud storage solution!
Backups
Since the backup policy depends on the needs and constraints of the data owner, cloud solutions providers hardly can propose backup solutions which can do it all. For sure, some providers propose backup tools and backup facilities, sometimes it's just an additional storage space.
The real technical solution to implement the backup policy can be built on top of these tools and facilities at disposition.
En effet, un hébergeur français bien connu a subi un sinistre sur une de ces sites de l'hexagone. Nombre de ses clients réalisaient bien des sauvegardes des données présentes sur ce site. Mais beaucoup d'ente eux stockaient les sauvegardes sur le même site. Lors du sinistre ils ont donc perdu les données originales et les sauvegardes !
Conclusion
Each enterprise or organization must implement its strategy to mix both storage redundancy and a global backup policy (derived for each business application or for each functional data set). Redundancy to address hardware failures and their impact on data instant availability. Global policy backup to address data loss of integrity but also availability loss.
When all the redondant hard disks were burnt to ashes during the datacenter/headquarters fire, the only thing left to resume IT production on an alternate location are the backups.
Le mix redondance/sauvegardes et la politique globale de sauvegardes doivent être pensés sous l'impulsion de la direction générale de l'entreprise ou de l'organisation. C'est une stratégie qui concerne en premier lieu les propriétaires des données, avant d'être une affaire d'informaticien·ne·s. Le rôle de l'IT est d'apporter l'éclairage technique nécessaire à la mise au point de cette stratégie ; de rappeler ce qui est faisable et à quel prix ; d'aider les directions générales et les équipes métiers à faire les arbitrages, y compris en matière de budget. L'IT ne peut pas se substituer aux propriétaires des données pour faire ces choix.
The backup policy and the storage redundancy policy are key elements of the strategy in the Information Security Management System (SIMS) in the scheme of ISO/IEC 27000 standards.
Remerciements
Je tiens à remercier Denis FOURNIER, ex-collègue et désormais ami, grand spécialiste des sauvegardes et de la restauration de données.
Pour sa précieuserelecture de cet article. Mais aussi et surtout pour le partage de son expertise sur le sujet, durant toutes ces années à ses côtés.
