Outils de déploiement #
Lors des tests automatisés des serveurs et des tests de PRA, le processus automatisé de Nuabee Backup introduit les drivers liés au redémarrage dans le Cloud. Cette introduction de drivers peut-être mise à mal par la configuration d’un outil de déploiement comme les produits de ManageEngine, PDQ ou équivalent.
- Si un de ces produits est présent dans votre environnement client, il faut penser à y enregistrer les drivers nécessaires au bon fonctionnement dans le Cloud des serveurs pour chacun des serveurs couverts.
Les drivers sont disponibles aux adresses suivantes (attention à bien installer les deux):
Sauvegarde serveur de fichiers Windows #
Si un serveur de fichiers comporte plus d’un million (1M) d’entrées, il sera demandé de vérifier les paramètres suivants:
Déplacement de la base de données Nuabee Backup vers disque SSD #
Afin de permettre au logiciel d’enregistrer les modifications apportées aux fichiers durant la période de rétention, Nuabee Backup enregistre celles-ci dans une base de données interne. Cependant, celle-ci peut peser lourd tant en taille sur le disque (peut dépasser la dizaine de GO) qu’en nombre d’entrées/sorties.
Pour en améliorer les performances, utiliser des disques / solutions de stockage à haut nombre d’entrée/sorties (IOPS) pour cette base de données est la meilleure solution. De plus, le simple fait de déplacer la base sur un disque ne comportant ni le système, ni les données sauvegardées aidera à la réalisation des sauvegardes.
Limite des 256 caractères NTFS #
Afin de limiter les problèmes de restauration, il est demandé de s’assurer de ne pas disposer de fichiers dont le chemin complet ne dépasse pas la limite Windows de 256 caractères.
Pour vérifier ceci il est possible d’utiliser un logiciel opensource, la command line CMD ou Powershell:
- GUI : pathlenghtchecker
- CLI Powertshell :
cmd /c dir /s /b |? {$_.length -gt 260}
- CLI CMD :
dir /s /b | sort /r /+261 > out.txt
Disposer d’une stratégie d’archivage des données #
Pour prévenir ce genre de problème et faciliter le travail de sauvegarde, il est utile mettre en place une politique d’archivage (au sens technique, via des conteneurs au format zip par exemple) des projets n’ayant pas pour but d’être modifiés.
Voici quelques cas pratiques :
- L’un des solutions est d’archiver les dossiers vers des fichiers zippés si son contenu n’a pas été modifié depuis plus de 3 ans.
- Les dossiers comportant un nom d’année sont généralement de bons candidats
- Les dossiers d’applications n’étant plus utilisées comportant des milliers de fichiers et librairies imposent un poids non négligeable au scan des fichiers modifiés, ceux-ci aussi peuvent être archivés.
- Les applications organisant leurs fichiers utilisés dans une arborescence Année / Mois / (Jour) / XXXXX doivent être vue comme problématiques. Idéalement, chaque jour / mois ou année doit être regroupé au sein d’une archive ( .zip par exemple) Pour limiter le coefficient de complexité du projet, le temps de restauration des données, la fiabilité de sauvegarde et le cout de la solution.
Disques Dynamiques Windows #
Selon la documentation de Microsoft(https://learn.microsoft.com/fr-fr/windows/win32/fileio/basic-and-dynamic-disks), les disques dynamiques sont dépréciés.
Il est alors demandé de basculer de disques dynamique vers disques classiques(https://learn.microsoft.com/fr-fr/windows-server/storage/disk-management/change-a-dynamic-disk-back-to-a-basic-disk) pour pouvoir prendre en charge la restauration appropriée des serveurs affectés.
Contrôleurs de domaine #
Accès de secours #
Il est recommandé de disposer de trois comptes « Administrateur du domaine »/ »Domain Admin » au minimum: un actif, un de secours et le dernier en cas d’extrême urgence, dont les credentials (nom d’utilisateur et mot de passe) sont externalisés dans un coffre fort (physique ou numérique) en cas de désastre/PRA.
Il faut aussi OBLIGATOIREMENT avoir gardé le mot de passe lié au « directory services restore mode » en s’assurant de l’avoir dans un gestionnaire de mot de passe.
Serveurs Linux #
Vérification de présence des drivers VirtIO au démarrage:
CentOS / RHEL 5 #
mkinitrd -f --allow-missing --with=xen-vbd --preload=xen-vbd --with=xen-platform-pci --preload=xen-platform-pci \
--with=virtio_blk --preload=virtio_blk \
--with=virtio_pci --preload=virtio_pci \
--with=virtio_console --preload=virtio_console /boot/initramfs-$(uname -r).img $(uname -r)Hyperviseur VMWare #
Changed Block Tracking (CBT) #
Lors de l’activation de la sauvegarde utilisant CBT, il est nécessaire de ne pas avoir de snapshots déjà présents sur les serveurs concernés.
Voir l’article sur l’activation ou désactivation du Change Block Tracking sur la sauvegarde
Problème de sauvegarde avec la version gratuite de VMware ESXI #
Il est important de savoir dans le cadre de la sauvegarde Nuabee que la version gratuite de VMware ne possède pas l’API vStorage,
Cette API VMware prend en charge un cadre de protection des données appelé vStorage API qui permet une sauvegarde centralisée des machines virtuelles au niveau de l’hôte. Les API vStorage permettent aux applications tierces de rendre la sauvegarde de VM efficace en consommant moins de ressources CPU, réseau et stockage.
La version gratuite d’ESXi Server ne permet pas aux applications d’interagir avec le serveur ESXi via les API vStorage. Par conséquent, les machines virtuelles ne peuvent pas être sauvegardées à l’aide de la version gratuite d’ESXi au niveau de l’hôte. Tenter de le faire entraînera une erreur : « La commande n’est pas prise en charge sur un objet distant ».
Afin de pouvoir sauvegarder vos VMs, il faudra au minimum une licence VMware Essentials et une version de vSphere égale ou supérieure à la version 6.5.