OVH Community, votre nouvel espace communautaire.

BackUp Système/DisqueDur Debian SYS


ssr
25/06/2014, 16h54
Merci Quazardous,
Tes conseils sont complementaires à ceux de philippe, çà m'arange bien
je ne pensai a l'image système pour faire des back-up, mais super, mieux vaut 3 backups, vu mes ""gros doigts"" héhé...
, donc j'install dans home plutot que dans "var/www"
1000 merci à toi, vous tiens o jus ^^

ssr
25/06/2014, 16h47
Génial Philippe, je recommence donc tout, gloups, en même temps çà devient un réel plaisir, quand on est soutenu, 1000 merci, j'y retourne donc

quazardous
22/06/2014, 00h01
moi je ferais une image système de la partition / à la mano de temps en temps en mode rescue histoire d'être sûr/ (tu fais un bête tgz à froid)

en cas de plantage du système (un upgrade foiré par exemple) tu as déjà ta partition système toute faite...

on peut bidouiller et faire des sauvegardes système à chaud mais...

PS : 2 jours c'est pas de la haute dispo...

pour les sauvegardes c'est pas très compliqué.

tes sites c'est que des fichiers (code+db).

donc faut mettre sur /home tous les fichiers des sites (le datadir de mysql, le www root, etc)

ensuite tu sauvegardes TOUS LES JOURS (merci les crons) :
- tout le repertoire datadir (ça c'est pour restaurer toute les bases rapido)
- chaque www root des sites
- un dump mysql de chaque base (ça c'est si t'as une panne serveur grave et que faut tout reinstaller)
- le repertoire /etc
- les logs (y a des lois y parait)

pour chacune de ces sauvegardes (sauf les logs) ça paut être bien de créer des versions :
- tu sauvegarde avec le jour du mois par exemple et tu copies avec le nom du mois

ex : masauvergarde-05.tgz et masauvegarde-janvier.tgz (si on est le 5 janvier)

tu te retrouves donc au bout d'un moment avec des versions de sauvergades tous les jours pendant 1 mois et mois par mois pendant 1 an...

c'est pratique si faut retrouver des trucs qu'on a supprimer sans le vouloir (merci les gros doigts) ;p

bien sûr tout ça on l'envoi sur le ftp storage...

EDIT : entre temp j'ai testé dump / restore pour les image system à chaud

dump -0af - / | gzip > monsystem.dump.gz

sur mon dédié le system centos qui fait 2.5 Go pèse 800 Mo en dump

phil
19/06/2014, 11h51
Pas de soucis.N'hésite pas à demander.

J'ai utilisé il y a bien longtemps webmin/virtualmin. L'idée de ces systèmes comme plesk ou autre est toujours la même. Backup des répertoires contenant les fichiers web, backup des bases de données, plus back-up des metadata, c'est à dire les infos type login, uid, gid, passwords etc. Et tar.gz de l'ensemble.

Je recommande vraiment d'éviter les plesk, webmin ou autre. Ce sont des outils d'aide à l’administration, ils ne dispensent pas de savoir administrer son serveur. Et ce dernier point est très mal compris jusqu'au jour où un désastre survient hack, perte des données, etc.)

Ceci dit, si tu n'as encore rien installé, je te propose :
  1. Dégage le netboot. Je ne suis vraiment pas convaincu par les noyaux OVH. Enfin, si tu as une raison précise pourquoi pas mais bon... Les noyaux debian sont pas mal.
  2. N'utilise pas Apache et passe direct à nginx. Il est mieux et plus facile à prendre en main. J'ai fait plein de tuto sur mon blog, dont un permettant d'optimiser son wordpress.
  3. Installe dotdeb. Tu as les dernières versions nginx, php etc. notamment le Zend opcache.


++

Philippe

ssr
19/06/2014, 10h46
hoooooooooooo, merci phil de ta réponse, je déseperai ,
haaa cool so i hope it will be bak-up soon ^^
wi des WP essentiellement
1000 thx: Philippe
J'étudie cette perle today & back to you soon

phil
17/06/2014, 14h56
Ben la question est de savoir ce que tu as à sauvegarder... "mes sites" c'est plutôt vague.

Si tu as des sites type wordpress ou autre, en gros, des machins php avec une BDD derrière, ce n'est pas trop dur. J'avais fait un tuto sur mon blog. Mais ensuite, c'est à adapter.

Philippe

ssr
16/06/2014, 13h27
bonjour Jibouch & Phil

Installé depuis 4jours sur une config "SYS : SSD-2 Xeon E3-1245v2 mais bien bleu en la matiere, je ne trouve pas dinfo et me permets ici de vous demander s'il y avait, a votre connaissance, quelque part un/des tutos (plutot des "pas a pas" enfin des explications claires), pour installer/configurer un "Backup Storage" & "netboot" j ai installé (pour l instant la debien 7.5, tt fonctionne, mais je n ose pas installer mes sites ...sans filet de protection ... merci mille fois d avance ^^

jibouh
17/04/2014, 02h00
Merci beaucoup.

phil
14/04/2014, 13h16
Coucou

Oui je repensais à ton pb. Si tu peux faire un rsync sur des fichiers ciblés dans le /etc, (ceux que tu as modifiés), à mon avis tu devrais être bon.

Le script était un super exemple. Je n'utilise pas le whiptail, mias ç'est une très bonne base.

J'ai hésité un certain temps à monter un hyperviseur sur mon SYS. C'est vrai que la back-up est super simplifié. Le snapshot te permet de faire des modifs en toute sécurité. Maintenant, toutes mes applis pouvaient tourner sur debian et je voulais les meilleurs perfs possibles sans l'overhead de la virtualisation.

++

Philippe

jibouh
14/04/2014, 01h22
Merci pour tes informations.

Je vais rester sur le principe de Rsync pour le back-up des données avec en amont, un sqldump périodique.

Le script est super, c'est donc Whiltail qui permet de répondre aux questions pendant les installations . Je pense pas aller aussi loin, mais c'est un excellent exemple !

Je pense que je vais me préparer une machine virtuelle à partir de ma procédure et de faire quelques scripts ou du moins, accélérer les copier-coller. Comme cela, si le service du client lâche pour une raison X ou Y, j'ai un système opérationnel sous la main... Je pense que je vais me mettre à virtualiser tous mes services quitte à avoir 1 Machine dédié pour 1 VM. Sinon, je vais passer trop de temps à faire des restaurations et le principe de duplication/export de VM est vraiment simple.


Encore merci

phil
10/04/2014, 19h14


Alors si t'as une procédure manuelle de ré-installation je dirais que tu es bon. Parce que tu peux savoir avec certitude où sont les données de config, utilisateurs, quels sont les paramètres à modifier et lesquels ne le sont pas...


Maintenant, le rsync, je n'utilise pas trop. Mais à mon avis tu as deux risques:
  1. Majeur: les bases de données. Un rsync d'une BDD active, c'est un désastre assuré.
    • La méthode propre consiste à stopper l'applicatif et utiliser mysqldump (ou équivalent).
  2. Je ne te garantirais pas que tu n'auras pas des effets de bord à restaurer avec un rsync le /etc/
    • Déjà tu as les init.d, rc?.d et un paquet d'autres trucs. Et pour peu que tu ne réinstalles pas exactement les même packages...
    • les configs réseaux, le fstab, des trucs liés au matériel qu'ovh vient peut-être de changer suite à un crash qui te force à ré-installer.
    • d'autres trucs que je maîtrise pas
    • Honnêtement, tu ne maîtrises pas quelle conf tu recharges, et ça ne me parait pas sain en général de ne pas maîtriser ce que tu fais sur ton système


Par contre, clairement, dans le /etc normalement tu as toutes les informations de ta configuration système (apache, mysql, php, nginx, bind, ntp, network, fstab, etc.). Mais tu as peut-être des configs spécifiques à tes applicatifs ailleurs dans l'arborescence. Dans mon cas, le teamspeak garde la config dans le répertoire d'install. So be it ! Mais ta procédure devrait t'aider à gérer cela.

Pour info, je me suis inspiré de ce post pour écrire mon script de restauration. Je ne connais pas tes besoins mais je dirais que normalement tu dois vraiment pouvoir tout faire. Dans le cas de tes users qui sont chrootés
  1. Leur uid et gid se retrouvent dans le /ets/password. Tu peux faire un script qui récupère leur uid/gid normalement > 1000 et qui les recrée avec les même uid/gid.
    • Hint: fait un grep sur les uid > 1000, utilise une boucle et chope les infos avec sed.
    • addgroup groupname --gid yyyy
    • useradd -u xxxx -g yyyy username
  2. Quand tu fais ton tar lors du backup/restore, ce dernier conserve toutes les infos ownership/timestamp. Un "cp -p" préserve lors de la copie. Le rsync aussi si je ne dis pas de bêtise.
  3. pour le chroot, c'est une config au niveau du ssh ou du ftp dans les /etc. Donc pareil, pas de soucis.


Est-ce que ça marche ?
Rsync, je sais pas, je n'ai pas essayé et je ne connaît pas trop. Ça me parait une bonne idée pour les données utilisatuers surtout si tu as du volume, moins pour les configs système.
Dans mon cas, j'ai 70Mo de backup, je suis parti d'un Kimsufi de 2010 et j'ai migré début mars avec mon script sur un SYS. Au passage, à la fin de migration, j'ai fait un rm * -R par erreur dans le /var/lib (no comment). Et il m'a fallut 30 min pour tout ré-installer de zéro. Depuis je tiens à jour mon script et je m'en sers régulièrement pour générer une VM sur mon PC qui me sers de banc de test.

Conclusion:
  1. C'est possible
  2. C'est portable
  3. C'est rapide
  4. Ça prend un volume ridicule (en dehors des données utilisateurs)


Maintenant, je ne fais qu'un back-up par jour parce que mes données ne bougent pas trop. Mais si tu me décris plus tes besoins (volume,cas d'usage, etc.), je peux essayer de te données d'autres solutions.

Philippe

jibouh
10/04/2014, 12h02
Bonjour.

Merci pour ta réponse.

Effectivement, j'ai une procédure qui retrace toutes les installations/modifications que j'ai dû faire.

Donc si je fait :
1 - Réinistallation des tous les paquets
2 - Rsync du dossier /etc/
3 - Rsync des dossiers de données.
Normalement, je récupère tout.

Il me reste quelques petits doute:
- Les fichiers de configuration user sont tous dans etc ?
- J'ai un user qui fait un Chroot sur un des dossiers de données. Ca ne posera pas de soucis ?

- Si j'ai bien compris, le dossier /etc ne comporte aucun paramètre matériel (Raid, partition, Usb, etc...), ce qui fait qu'avec ta méthode, il n'y a plus de soucis de portabilité entre différentes machine.

Encore merci Phil, c'est la seconde fois que tu m'aiguilles. A quand un forum.phil.com ^^

phil
10/04/2014, 10h48
Bonjour

J'utilise une solution différente pour mes back-ups à l'aide de scripts.
  1. un back-up des données "clients" => tar -Jcf $BACKUP-FILE $DIRS
    • Le -J utilise un algo un peu plus performant que le gzip classique
  2. dump et compression des bases de données (mysql)
  3. une copie du répertoire /etc/


Fondamentalement, mes back-up représentent 70Mo après compression. Et encore, je pourrais certainement optimiser. Par exemple, tu peux faire des back-ups incrémentaux, seuls sont pris dans le back-up les fichiers nouveaux et modifiés par rapport au dernier back-up complet.

Ensuite, j'ai créé un script de restauration qui ré-installe le serveur de zéro à partir du dernier back-up. Dans mon cas, j'ai des serveurs web (apache+nginx) avec base de données mysql, un team-speak, etc. Le script va
  1. ré-injecter les IP-FO dans la conf réseau
  2. installer à coup d'apt-get apache, nginx, mysql ainsi que tous les packages dont j'ai besoin (bind, ntp, php5-*, etc.)
  3. ré-installer les services de bases (bind, ntp, fail2ban, etc.) en modifiant les fichiers de config comme il faut
  4. recréer les base de données à partir des dumps
  5. récupèrer les confs des sites webs nginx et apache, les recopier dans les répertoires ./sites-available et les activer en recréant les liens symboliques adéquats ou a2ensite
  6. recopier à partir des back-up les contenus des répertoires /var/www, les clés ssl des serveurs, etc.
  7. recréer la configuration iptables
  8. recharger la dernière version de teamspeak
  9. copier la base de donnée teamspeak et les fichiers utilisateurs là où il faut ainsi que les scripts de démarrage du service
  10. etc.


J'ai même passé en variable les différentes IP du serveur. En gros, ça me permet à coup de SED à la copie des fichiers de config de changer les IP et IP_FO du serveur. Ainsi, je peux installer sur une VM debian chez moi une copie de mon serveur qui me sert alors d'environnement de test. En fait, je passe dans le /etc/host les différents noms de domaine de mon serveur, comme ça, je monte aussi un proxy et je configure mon firefox pour utiliser le proxy de ma VM => je peux naviguer sur mes sites hébergées par ma VM de test avec leurs vrais noms de domaine et tester mes modifs en live !!

Bref, j'ai déjà testé une fois mon script de réinstallation après une fausse manip. Il m'a fallut 30 min pour tout réinstaller de zéro. Zéro étant défini comme le formatage du serveur depuis l'interface SYS avec les bons partitionnements.

Je suis un peu rentré dans les détails pour te montrer ce qui est possible. Mais ce qu'il faut retenir est que
  1. Les données "clients" et les bases de données, tu ne maîtrises pas trop leurs tailles
  2. La partie système d'un debian, ça peut tenir dans un tar du répertoire /etc/ + quelques fichiers de configs supplémentaires ailleurs, et un bon script de restauration. Maximum: 100 ko !!
  3. pour peu que tu maintiennes à jour ton script de restauration, reconstruire ton serveur après un désastre ne devrait jamais te prendre plus de 30 min. Sauf si tu as 100 Go de données clients à recharger depuis ta ligne ADSL bien sûr.


Voilà, j'espère que cela répondra à ta question initiale.

Philippe

jibouh
06/04/2014, 18h00
Bonjour à tous,

Je vous écris car j'ai un soucis qui me donne du fil à retordre...

Je possède un serveur SYS E32-1 avec une configuration "standard"
- Raid1 logiciel
- Partition / de 20Go
- Partition /home de 2To

J'ai besoin d'une haute disponibilité sur le serveur (grand max 2jours d'interruption). J'ai donc besoin d'avoir un backup du système.

Concernant les données du 'SI', je réalise un Rsync à destination du serveur de backup.

Cependant je n'arrive pas à faire un vrai backup du système. Je n'ai pas besoin d'un backup régulier du système, un seul me suffira car j'effectue séparément le backup des données.

J'ai essayé plusieurs méthodes qui ont toutes échouées :

1 - Copie du sdA (conprenant Sda0 --> SdaX) via --> dd if= of=.img bs=4k
Via le bs=4k, je récupère une image (.img) du disque dur d'environ 200Go

J'ai essayé d'intégrer cette image dans une VM (libvirt) et le système refuse de boot ---> Panic Kernel...

2 - Copie du contenu des partitions / et /home puis intégration sauvage de ces partitions dans une VM debian à la place de ces partitions / et /home d'origine...
Je parle de sauvage car je comptais ensuite reconstruire le grub de cette VM.

D'un coté, c'est logique que ça ne fonctionne pas mais bon...


Après ces séries de tests, je pense avoir identifié les problèmes
- Le système debian gère le raid logiciel, il ne peux donc démarrer sur une VM avec uniquement les données du Sda vu qu'il tourne sur du Md.
- Le partitions ont des UUID.

Ma question est donc simple, comment faire un Backup de mon serveur ? (mais la réponse est compliqué...) :

- je ne pense pas que le service FTP-backup puisse suffire car il dispose uniquement de 100Go; Quoique, si je peux faire uniquement le backup de la partition / (de 20Go), c'est parfait. Il me suffit de gérer la partition /home. ce qui avec un Rsync me posera pas de problèmes.

- Si l'on considère que mon serveur est totalement corrompu , deux solutions s'offre actuellement à moi :
A- Je fait une réinstallation (via SYS) de ma débian avec les même paramètres de base (/ - 20Go et /home avec le reste du disque en Raid1).
Puis en mode Rescure, je fait un Rsync du backup de / sur le / de ma nouvelle installation puis de même avec le backup de /home sur la partition /home.
En théorie, il faudrait que je face cela sur le Sda et le Sdb du serveur nouvellement installé car je ne crois pas qu'en mode rescure la partition Md soit prise en compte.

Est ce qu'une copie brut sur Sda et Sdb fera l'affaire ? Si l'image d'install Debian d'OVH est modifié, aurait je un soucis avec la table de partition ? Faut il faire une reconstruction du raid ?


B - J'ai un backup du Sda.img obtenu via dd et le paramètre bs=4k afin d'avoir une img de 200Go au lieu de 2To.

Est ce qu'une copie de cette image sur le Sda et le Sdb du serveur à reconstruire peut fonctionner ?
Y a t il un paramètre particulier à spécifié à DD pour que l'image de 200go reprenne sa place de 2To sur le disque dur ?
Y a t il un risque que cette méthode ne fonctionne pas si je change de serveur ? ou uniquement de modèle de disque dur ?


Dans tout les cas, ces éventuels solution ne me convienne pas vraiment:
- Je ne peux la transporter sur une VM libvirt
Si j'ai bien compris, la distri Debian d'OVH ne prend pas les paramètres de virtualisation.
- Si je change de serveur pour une raison X ou Y , je risque d'avoir de sérieux soucis de portabilité.

Je pense que deux solutions pourrait répondre définitivement à mon soucis:
1 - Pouvoir faire un export de la configuration logiciel de ma Debian. Cela prendrais les logiciels installé, la configuration de ceux ci, les users/group.
Cette méthode me permettrai d'importer cette configuration sur tout autre Debian du moment que ce soit une wheezy.
Cela aurait le grand avantage de m'affranchir totalement de la gestion matériel assuré par debian. Libre à moi de gérer uniquement /home

2 - Je me débrouille pour passer la configuration de mon serveur physique compatible avec un système de VM. Si j'ai un soucis, je garderai la VM ou j'exporterai la VM sur un autre serveur physique, quitte a utiliser libvirt pour l'utiliser.

Pour arriver à mes fins, il faudrait (avec les risques que cela comporte) que je désactive le Raid sur mon serveur et "supprime" le disque Sdb. Une fois la configuration de Debian réalisé, je fais un backup.img du Sda et la test dans une VM.
Mais, je crois que j'aurai d'autres soucis:
- La distri debian OVH, ne possède pas les librairie de virtualisation KVM (enfin je crois)
- La distri OVH, ne permet pas d'ajouter de module et les librairies de virtualisation sont des modules (enfin je crois).
- DKMS pourrait faire l'affaire ?


Je suis sur qu'il y a une solution "simple" pour résoudre mon problème mais je n'ai pas trouvé...

Au plaisir de vous lire.

Merci.