Hello !
Faire des backups réguliers (et fiables si possible...), disposer d'un serveur de secours prêt à l'emploi (si c'est possible). Pas possible pour le moment.
Les backups c'est obligatoire. (Perdu 2 ans de boulot perso il y a 15 ans, je m'en souviens encore très bien, surtout les "sensations" qui remontent du bas du dos jusqu'à la nuque...) Concernant le serveur de secours, deux solutions : 1) un autre auto-hébergé partage son CPU, un peu de mémoire, de l'espace disque et surtout sa bonne humeur pour t'allouer une ou plusieurs machines virtuelles au sein de son serveur. Le principal problème, c'est IPV4 : les FAI n'allouent qu'une seule IPV4 par abonné donc si tu as besoin de faire tourner un serveur web, mail, ftp, etc. ça va pas être possible à moins d'utiliser sur le serveur hôte plusieurs reverse proxy pour rediriger les requêtes vers la bonne VM. (testé, ça marche mais disons que c'est un plutôt "chiant") Par contre, en IPV6, pas de souci, au final c'est du routage tout bête. 2) louer un VPS chez un hébergeur low-cost (ou plus sérieux) Pas testé. (Et ce n'est plus de l'auto-hébergement pur jus donc forcément c'est mal ! ^^) Plus sérieusement, attention aux offres low-cost, la plupart du temps les hébergeurs font de l'overselling comme des malades, c'est à dire qu'ils "bourrent" leurs serveurs en tablant, d'après leurs stats, qu'aucun client n'utilisera vraiment les ressources dont il a droit. Évidement, pour une bascule rapide, le VPS doit être loué avant la panne et être régulièrement synchronisé afin de disposer des backups récents. Sauf erreur, on ne peut pas installer un système de virtualisation sur ce genre de VPS (techniquement c'est possible mais, d'un point de vue commercial, cela revient à se tirer une balle dans le pied et comme les marketeux "dirigent" le monde, c'est mort, du moins pour l'instant).
Il manque des infos pour être précis : OS, services utilisés, espace disque utilisé, etc. Gnu Linux debian avec du web, git, dns. Très faible espace disque utilisé (qq % sur un To)
Un VPS (chez un autre auto-hébergé ou payant) fera largement l'affaire.
Je bosse justement en ce moment sur des scripts permettant d'effectuer des sauvegardes/réplication/restauration de containers OpenVZ et d'ici peu de temps les scripts seront disponibles sous licence GPL v3. Pour la virtualisation j'utilise Proxmox : ça m'a changé la vie. :) Je note, ça semble très intéressant, merci !
Les scripts fonctionnent mais j'ai un problème au niveau des IOPS générés sur le serveur distant, celui qui reçoit les backups. Je pensais dans un premier temps avoir résolu le problème mais en fait non. Du coup je teste autre chose. Comme d'hab cela semble prometteur mais je ne m'emballe pas pour autant car, même si les tests sont pour l'instant plutôt concluants, on va voir à l'usage. L'idée est de conserver un historique de 30 jours d'un serveur complet.
Dans le monde théorique, vrai. Dans mon monde pratique, ça l'est moins. Des raisons : * C'est de l'auto-hébergement, mais le serveur n'est pas chez moi mais chez des gens qui n'ont pas les compétences d'intervenir dessus. * Le système d’accueil est ce que je trouve (netbook, vieux trucs qui traînent... et pourquoi pas un serveur non accessible physiquement)
Contacte Exca, il est dans la même problématique : son serveur n'est pas accessible physiquement et pourtant son uptime est très bon.
J'ai assisté ce week-end à une présentation sur python fabric qui va dans ce sens. Je vais explorer aussi cette piste. Merci.
Il y a aussi Csync2 qui peut servir. A+ -- tranxene50 tranxene50@developpeur-neurasthenique.fr