En cours de traduction

Pour BeezNest, la sécurité de vos informations est importante. C'est pourquoi nous faisons tout ce qui est en notre pouvoir pour vous offrir des systèmes de gestion de l'information d'un niveau très élevé de sécurité. Dans cette optique, notre équipe compte parmi ses rangs un spécialiste de la norme ISO/IEC 27001:2014 qui garantit un niveau minimum de sécurité au niveau de la gestion des systèmes d'information. Celle-ci inclut notamment le critère de disponibilité des données, qui veille à garantir la disponibilité en tous temps des données du système, notamment en cas de pertes. Si un système sans copie de sauvegarde (pour des limitations de budget) était victime de l'exploitation d'une faille de sécurité, notre service de backup vous permettrait de récupérer le système complet dans un état antérieur. Soucieux de clarté dans la gestion de vos données, nous détaillons ci-dessous nos processus en termes de prise de copies de sauvegarde, afin que vous compreniez ce que nous vous offrons et dans quelle mesure cela peut vous être utile à l'avenir.

Périodicité

Une copie de sauvegarde n’est pas un mécanisme de réplication ni de redondance. Dans ce sens, un backup n’est pas généré à chaque seconde, chaque minute, ni même chaque heure (encore que nous avons déjà géré la prise de backups horaires dans des cas précis et pour des durées de temps limitées)

Au lieu de cela, nous prenons des copies de sauvegarde tous les jours. Ceci signifie que, chaque nuit, pendant que votre application est moins utilisée, nos serveurs de backup se connectent à votre serveur pour en extraire une copie des données concernées (il ne copie pas tout, seulement ce dont le serveur a besoin pour que l’application continue de fonctionner si on la transporte sur un autre serveur préparé à cet effet)

Persistance

Un backup a une vie utile spécifique. S’il est renouvelé chaque jour, nous ne conservons pas éternellement une copie d’un jour déterminé, mais bien pendant une durée limité. Pour comprendre la logique générale de la période de persistance, le plus simple est de prendre un calendrier et d’y penser comme suit:

  • nous gardons un backup chaque jour pour les 7 derniers jours
  • passés les 7 jours d’ancienneté, nous ne conservons que le dernier jour utile de la semaine (en général durant la nuit du samedi au dimanche), et cela pendant 3 semaines
  • passées les 3 semaines, nous ne conservons que le dernier backup utile du mois (sur base d’un backup hebdomadaire)
  • ce backup mensuel est conservé 3 mois (donc 3 backups) avant d’être supprimé à tout jamais

Chaque backup qui dépasse les 7 jours et qui n’est pas le dernier de la semaine est totalement supprimé de nos serveurs. Il n’en reste aucune trace. C’est pourquoi nous ne pouvons pas forcément récupérer un backup d’un jour précis (si celui-ci date de plus d’une semaine), mais généralement de quelques jours plus tôt ou quelques jours plus tard.

Indépendance géographique

Notre centre de backup est hébergé en Belgique, dans un centre de données propre à BeezNest, et donc distant des serveurs utilisés pour l’hébergement de votre application. Ceci garantit une très basse probabilité de perte, même en cas d’attaque nucléaire ou de cataclysme.

Sécurité

Nos serveurs de backup se connectent à votre serveur au travers du protocole SSH, basé sur un chiffrement avec SSL. Nous mettons nos systèmes à jour régulièrement pour maintenir un très haut niveau de confidencialité de vos données durant leur transfert sur le net.

Seuls nos administrateurs « senior » ont accès aux serveurs de backup, ce qui garantit encore plus la confidentialité. Les serveurs sont protégés par des mécanismes simples mais éprouvés: ouverture de ports limitée à ceux strictement nécessaires, ces serveurs étant spécifiquement dédiés à l’activité de backup.

Temps de récupération

Le processus de récupération des backups est un élément séparé du service de backup, étant donné qu’il combine de multiples compétences (équipes de support, administration système et développement). Il vous sera donc nécessaire de compter sur un service de support actif avec nous afin que nous puissions nous charger de votre demande de restauration d’un backup. Le temps nécessaire pour la restauration d’une application dépend de nombreux critères (dont l’espace total utilisé).

Par exemple, si votre serveur n’est pas hébergé chez nous, la restauration du service pourrait prendre beaucoup plus de temps en raison des coordinations avec votre hébergeur ou votre équipe informatique, et du temps de transfert.

La récupération du système peut être soumise à des facteurs externes hors de notre contrôle.

Le type de restauration souhaité (voir point suivant) peut grandement affecter le temps nécessaire à la restauration.

Récupération intégrale ou partielle

Nos backups sont pris de manière intégrale, dans le sens qu’ils ne font pas la différence entre une partie ou l’autre de l’application sauvegardée. Si vous utilisez un site Drupal et que vous nous demandez de récupérer une page spécifique, il est possible que cette restauration prenne beaucoup plus de temps qu’une restauration complète. En effet, cette page peut avoir été remplacée par une autre qui ne peut pas être éliminée, ou elle peut contenir de nombreuses relations vers d’autres pages qui furent, elles, éliminées également au moment de détruire la page principale. Si vous utilisez Chamilo ou Skillms, récupérer un cours en particulier peut prendre beaucoup plus de temps que de récupérer le système complet, à cause des « autres » changements qui se sont produits sur le système après avoir perdu la information du cours en question.