Votre première option est de tester votre restauration avec des données réelles afin de voir tout ce que votre configuration de serveur fait qui n'est pas couvert par une Time Machine.
Vous voudrez aussi vous procurer un outil comme Bender pour gérer l'exportation et l'importation des paramètres dans le server.app lui-même.
Idéalement, vous disposez d'un document d'installation dans lequel vous avez consigné chaque élément configuré, car il vous servira de liste de contrôle pour vérifier que tout est couvert.
- Avez-vous configuré un emplacement de données alternatif pour certains des services ?
- Avez-vous "corrigé" des fichiers point pour les utilisateurs et exécuté des commandes de terminal ?
- Avez-vous des tâches launchd qui ne sont pas packagées (je fais souvent des changements de routage et autres qui s'exécutent pour définir des routes statiques, rouler sur les fichiers journaux des applications, etc...).
Le serveur est une bête différente et vous pouvez et allez mettre en place de nombreuses bases de données importantes - dont certaines doivent être archivées et restaurées ultérieurement, comme le courrier, le web, LDAP. Au fur et à mesure que votre serveur se développe, vous en viendrez à considérer chaque donnée comme distincte, car les sauvegarder toutes à la même fréquence ou avec le même mécanisme n'est pas une bonne solution sur le plan technique. Time Machine est un point de départ, pas un point d'arrivée et l'utilisation d'une technologie miroir comme Carbon Copy Cloner ou SuperDuper ! n'est généralement pas la solution, car il faut souvent un jour ou deux pour restaurer des téraoctets de données, alors que vous pouvez avoir ces données sur une appliance de stockage et utiliser vos sauvegardes de système d'exploitation et de configuration pour sauvegarder la colle, le code et les outils, pas le produit.
