Sauvegarde serveur Debian
Bonjour, en arrivant au boulot ce matin (je suis stagiaire) je me suis aperçus qu'un des processeur d'un de mes serveur etait mort.
J'ai 2 serveurs:
Celui qui moeur: 172.16.32.242
Le second qui est dans ma DMZ 172.16.64.243
Alors avant que le second processeur ne moeur, je voudrai faire une sauvegarde complete du serveur 32.242.
Ce serveur sert de serveur de stockage de donnée et aussi de serveur SMTP.
Question: Conaitriez vous une procedure qui me permette de sauvegarder ce serveur proprement?
Deuxiemement, je voudrai passer le service SMTP du serveur 32.242 au serveur 32.243. Y a t'il un moyen fiable pour le faire? (que les utilisateurs ne s'aperçoivent de rien car ces deux serveurs sont en production)
Merci a vous tous,
Benjamin
J'ai 2 serveurs:
Celui qui moeur: 172.16.32.242
Le second qui est dans ma DMZ 172.16.64.243
Alors avant que le second processeur ne moeur, je voudrai faire une sauvegarde complete du serveur 32.242.
Ce serveur sert de serveur de stockage de donnée et aussi de serveur SMTP.
Question: Conaitriez vous une procedure qui me permette de sauvegarder ce serveur proprement?
Deuxiemement, je voudrai passer le service SMTP du serveur 32.242 au serveur 32.243. Y a t'il un moyen fiable pour le faire? (que les utilisateurs ne s'aperçoivent de rien car ces deux serveurs sont en production)
Merci a vous tous,
Benjamin
A voir également:
- Sauvegarde serveur Debian
- Logiciel de sauvegarde gratuit - Guide
- Changer serveur dns - Guide
- Sauvegarde facile - Télécharger - Sauvegarde
- Sauvegarde android - Guide
- Serveur dns gratuit - Guide
5 réponses
Pour le backup peut importe l'état du microprocesseur, si tu as accès au disque tu pourras toujours récupérer tes données. Ceci dit, tant qu'il est en vie des commandes comme rsync ou scp (présuppose qu'un serveur ssh soit installé et lancé sur le serveur à backuper) pourraient t'aider.
Pour que la passation de pouvoir se fasse sans douleur au niveau SMTP, on peut raisonnablement supposer que tes utilisateurs passent par un DNS pour préciser leur serveur SMTP (par exemple smtp.pouet.fr et non 172.16.32.242) . Il suffirait donc de faire en sorte que tu changes l'adresse associé au nom smtp.pouet.fr pointe sur 172.16.64.243 au niveau du serveur DNS de ton entreprise.
Bonne chance
scp -r login@ipserveur:/le/repertoire/a/copier /le/repertoire/dans/lequel/je/recopie
Pour que la passation de pouvoir se fasse sans douleur au niveau SMTP, on peut raisonnablement supposer que tes utilisateurs passent par un DNS pour préciser leur serveur SMTP (par exemple smtp.pouet.fr et non 172.16.32.242) . Il suffirait donc de faire en sorte que tu changes l'adresse associé au nom smtp.pouet.fr pointe sur 172.16.64.243 au niveau du serveur DNS de ton entreprise.
Bonne chance
Ben si par exemple tu veux te connecter en root sur la machine pouet.plop.com qui a pour IP 11.22.33.44, au choix :
Même principe pour scp.
http://doc.ubuntu-fr.org/ssh
Au préalable il faut installer ssh server :
Bonne chance
ssh root@11.22.33.44 ssh root@pouet.plop.com
Même principe pour scp.
http://doc.ubuntu-fr.org/ssh
Au préalable il faut installer ssh server :
aptitude update aptitude safe-upgrade aptitude install openssh-server
Bonne chance
Le probleme c'est qu'avec cette commande les proprietaires des fichiers sont tous modifié en "root" sur la copie :/
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Non non l'option -p n'existe pas :-) En fait c'est assez logique que les permissions soient modifiées :
- la commande cp se comporte de manière identique
- certains utilisateurs n'existent potentiellement que sur une machine
- quand un utilisateur mando rappatrie des fichiers dans ses documents, il a potentiellement envie de pouvoir les modifier à son idée.
Si tu es dans le cas "favorable" ou chaque droit est bien cloisonné par arborescence (typiquement /home/mando appartient à mando etc...) il sera toujours possible de s'en sortir a posterio avec la commande chown.
Sinon ça risque d'être bien plus compliqué. Peut-être qu'en faisant une archive au préalable les uid ne seront pas impactées (à tester).
Sur le serveur à sauver, en root :
Sur la machine de récupération :
Si ça te convient, je pense que tu peux directement "fusionner" le /home/mando de l'archive avec celui de la machine de récupération, il suffit de décompresser dans / au lieu de décompresser dans ~. Les fichiers de l'archive écraseront les éventuels fichiers existant dans l'arborescence de la machine de récupération en cas de collision. Donc attention à ce que tu fais.
Bonne chance
- la commande cp se comporte de manière identique
- certains utilisateurs n'existent potentiellement que sur une machine
- quand un utilisateur mando rappatrie des fichiers dans ses documents, il a potentiellement envie de pouvoir les modifier à son idée.
Si tu es dans le cas "favorable" ou chaque droit est bien cloisonné par arborescence (typiquement /home/mando appartient à mando etc...) il sera toujours possible de s'en sortir a posterio avec la commande chown.
chown -R mando:users /home/mando
Sinon ça risque d'être bien plus compliqué. Peut-être qu'en faisant une archive au préalable les uid ne seront pas impactées (à tester).
Sur le serveur à sauver, en root :
cd tar cvzf mando.tgz /home/mando
Sur la machine de récupération :
cd scp root@ip_serveur:mando.tgz . tar xzvf mando.tgz
Si ça te convient, je pense que tu peux directement "fusionner" le /home/mando de l'archive avec celui de la machine de récupération, il suffit de décompresser dans / au lieu de décompresser dans ~. Les fichiers de l'archive écraseront les éventuels fichiers existant dans l'arborescence de la machine de récupération en cas de collision. Donc attention à ce que tu fais.
mv ~/mando.tgz / tar xzvf /mando.tgz
Bonne chance
Je vous tiens au courant.
Tu veux dire que je peux mettre "root:"?
Les ":" sont bien a mettre?
Merci,
Benjamin