Utilisation de tar et rsync pour une haute disponibilité

J'ai des serveurs cloud Ubuntu en cours d'exécution auxquels je n'ai pas accès directement mais avec ssh. J'utilise 'tar' pour cloner ou pour avoir une haute disponibilité de ce serveur. J'ai suivi le tutoriel du lien [texte du lien] [1]. J'ai essayé d'installer un nouveau serveur de la même version. Lorsque j'ai extrait le tar (tar -xvpzf ~ / clone.tgz -C /) sur la destination (nouveau), à la fin, il se termine par la sortie suivante similaire à celle ci-dessous (je ne sais pas si c'est une erreur).

tar: var/run: time stamp 2010-11-09 17:09:11 is 7335.159880406 s in the future
tar: var/spool/postfix/usr/lib/zoneinfo: time stamp 2010-11-09 17:08:26 is 7290.159730037 s in the future
tar: var/lib: time stamp 2010-11-09 17:27:51 is 8455.159349527 s in the future
tar: usr/bin: time stamp 2010-11-09 17:28:02 is 8466.159254097 s in the future
tar: usr/share/sgml: time stamp 2010-11-09 17:27:47 is 8451.158909506 s in the future
tar: usr/share/man/man7: time stamp 2010-11-09 17:27:50 is 8454.158393583 s in the future
tar: usr/share/man/man1: time stamp 2010-11-09 17:28:02 is 8466.158166556 s in the future
tar: usr/share/man/man8: time stamp 2010-11-09 17:27:51 is 8455.158057701 s in the  future
tar: usr/share/omf/time-admin: time stamp 2010-11-09 17:27:52 is 8456.157830449 s in the future
---------------------------------------------
---------------------------------------------
---------------------------------------------

J'utilise la commande suivante pour créer un fichier tar des répertoires spécifiés sur le système source.

tar -cvzf ~/clone.tgz --exclude ~/clone.tgz --exclude /etc/hosts --exclude /etc/hostname --exclude /etc/udev/ --exclude /etc/network/interfaces --exclude /etc/resolv.conf  /etc /home /opt /tmp /usr /var /mnt

• Y a-t-il des précautions avant d'utiliser du goudron? (le tar est une création unique à partir de ce moment-là, je vais utiliser rsync)
• Dois-je inclure d'autres répertoires comme bin ou lib? - suggère moi
• Dois-je exclure un répertoire? Comme si j'avais un problème de périphérique réseau (eth0) (impossible de démarrer eth0). Donc, dans la commande ci-dessus, j'ai exclu "/ etc / udev /" et après cela, j'ai senti que c'était bien. Comme ça, y a-t-il quelque chose que je dois exclure de / etc / ou de tout répertoire que j'ai inclus? - suggère moi.
• Comment pourrais-je planifier rsync (bkp incrémentiel) avec la combinaison ssh pour synchroniser les répertoires (spécifiés dans tar) vers l'emplacement distant (disons / mnt / newdir) que je pourrais tarer et extraire plus tard en cas de défaillance du système. Rsync peut être programmé pour s'exécuter en tant qu'utilisateur root mais le ssh vous demandera le mot de passe. Pour info, sudo est complètement désactivé et la connexion directe ssh à root est également désactivée.

S'il existe un meilleur moyen sans aucun dommage au serveur pour y parvenir, peut suggérer.

[1]: http://ubuntuforums.org/showthread.php ? t = 525660

Je vous recommanderais d'utiliser rsync à la place, cela vous permettra de faire une synchronisation réelle du système au système sans avoir besoin de fichiers temporaires. Il offre également l'avantage d'effectuer des mises à jour incrémentielles lorsque vous devez mettre à jour le clone.

J'exclurais seulement: / proc / / sys / dev / tmp / mnt Sur le système de clonage, vous devrez vous assurer que / etc / fstab et /boot/grub/grub.cfg sont mis à jour avec les UUID des partitions des systèmes de clone.

Si vous avez une base de données comme mysql, vous devrez faire attention et arrêter la base de données avant d'effectuer la copie.

Tout d'abord, de nombreux fournisseurs de cloud IaaS offrent de puissantes capacités d'instantané qui résolvent assez facilement ce problème.

Sur EC2, si vous exécutez un système basé sur EBS, vous pouvez simplement le prendre périodiquement en photo. Si quelque chose de terrible arrive à l'instance source, vous pouvez revenir à l'instantané précédent sur une toute nouvelle instance. Si vous souhaitez archiver un instantané, vous pouvez démarrer une autre instance avec lui attaché et utiliser quelque chose comme tar + s3 sans impact négatif sur la boîte de production.

Il y a un certain nombre de problèmes avec cette approche qui peuvent ne pas être apparents en ce moment.

1. Vous vous enfermez dans une seule technologie. Si cela fonctionne sur Ubuntu 10.10 et que vous souhaitez passer à 11.04, vous devez mettre à niveau le système source, puis le recréer. De même, si vous utilisez des instantanés EBS d'EC2, vous avez besoin d'une nouvelle solution si vous allez sur le cloud de rack.
2. Vous n'avez aucun historique des modifications si vous utilisez rsync. Si vous modifiez quelque chose sur le système 1, puis quelque chose se casse, vous casserez probablement aussi votre système de sauvegarde lorsque vous rsync.
3. Rsync peut avoir un impact extrêmement élevé sur votre système de production.

Ce que vous voulez vraiment, c'est un système de gestion de configuration et une haute disponibilité des données.

Je vous recommande de choisir un système de gestion de configuration, comme marionnette (en principal!), Chef ou cfengine. Commencez à faire toute votre configuration dans le système de gestion de la configuration, puis vous pouvez simplement démarrer un système générique et lui appliquer la gestion de la configuration. Ajoutez 'etckeeper' et vous avez l'historique.

Pour la haute disponibilité des données, rsync devrait fonctionner et être beaucoup plus simple car vous pouvez simplement copier les données que vous souhaitez. Il y a aussi drbd pour avoir ce qui équivaut à un "réseau RAID1". Ce ne sont pas des remplacements pour les sauvegardes de données, qui devraient inclure des instantanés historiques (que ce soit via des instantanés de périphérique de bloc ou quelque chose comme tar) plutôt que de se synchroniser avec un hôte de récupération (que faire si quelqu'un supprime toutes les données qui sont synchronisées dans la boîte de récupération, en les supprimant toutes ici aussi?)

Les messages sont probablement dus au fait que la nouvelle horloge du serveur est en retard par rapport à l'ancienne.

Si vous clonez la configuration et la base de données du gestionnaire de packages (et vous l'êtes), vous devez cloner / bin, / sbin et / lib ou le système de destination sera dans un état incohérent. Une autre approche consistera à exclure /etc/dpkg.info / etc / apt / var / lib / apt et / var / lib / dpkg et à réinstaller tous les packages dans le système cible.

Les fichiers dans / var / dpkg et / var / apt contiennent des informations sur ce qui est installé sur votre système. Si vous ne les excluez pas, le gestionnaire de packages pensera que tous les programmes et dépendances du système parent sont installés dans la cible. Mais si vous n'avez pas copié / bin, / sbin, etc ... ils ne le feront pas. Il est très probable que quelque chose se cassera lors de la prochaine installation ou mise à jour.

Pour rester synchronisé avec rsync, j'ai toujours utilisé une authentification basée sur un certificat, pas des mots de passe. C'est assez facile à configurer, je me souviens que je l'ai fait juste en lisant la page de manuel la première fois. Voici un petit guide , si vous voulez plus d'informations je pense que cela mérite une nouvelle question.