Pour les clients sous Windows, c'est faible. La méthode smb est lente, celle par rsync pas idéale et moisn rapide que pour un Linux. Pas de support du shadow copy de Windows. Un client windows serait je pense une bonne chose.
Backuppc a des soucis si la taille des données sur un poste sont trop grosse et puis la restauration se fait sans gestion des droits. Du coup, j'ai fait une moulinette qui à partir d'un fichier YAML génère autant de fichier pour backuppc qu'il y a d'utilisateur. Ainsi chaque utilisateur peut avoir accès a sa seule sauvegarde. J'ai ainsi des machines ayant plus de 1500 fichiers de conf chacune ! backuppc s'en sors très bien mais si on limite a 5 sauvegarde parallèles, il ne voit pas qu'en pratique, il sauve 5 fois la même machine physique mais des dossiers différents. On pourrait avoir un paramètre qui limite le nombre de rsync sur les machines physiques.
Pour info, mon script YAML me récupère via une requête rsync la liste des sous dossier des home, interroge le LDAP pour savoir si le compte associé est actif et génère alors le fichier de conf. Ainsi, le backup s'arrête tout seul lorsque les personnes partent !
Backuppc a le même soucis que pas mal de logiciel, il est basé sur les noms DNS ou quasiment pareil (au DNS dyn près) sur l'IP. Dans un monde en mobilité, c'est plus tout à fait adapté. A noter que ssh, cfengine… ont le même défaut !
Il y a des batailles pour savoir s'il vaut mieux du push ou du pull ! Moi, je n'aime pas que tous mes clients puissent lancer eux-mêmes leur sauvegardes et donc écrire sur le serveur. Cependant, si une personne est chez elle, plus de backup… Je pense que cette architecture est périmé. Ni push, ni pull sont bon à mon avis.
Il faudrait un agent sur le poste qui fait acte de présence sur le serveur en donnant son nom (type XMPP) et ouvrirait un port en retour via le tunnel ainsi crée. Le serveur central ferait alors quand il le décide une copie de backup en utilisant le tunnel ouvert par le client. Ainsi, le serveur pourrait faire un backup d'une machine située n'importe ou dans le monde.
Rsync, c'est bien mais on voit bien sur des très grosses partitions que la phase initiale est longue. Il faudrait pouvoir faire cela sur un snapshot LVM qui ne duplique pas les inode mais ne conserve que la trace des block modifiés (j'ai vu une fois une personne qui avait fait un patch la dessus). Le backup serait alors bien plus rapide. Autre solution, utiliser lsyncd pour conserver la liste sur le client des fichiers modifiés entre deux sauvegardes. On devrait pouvoir aller encore beaucoup plus vite.
Je pense que la notion de backup incrémentale et complète est complètement dépassé lorsqu'on travaille sur disque. On ne veux voir que des complètes tous les jours, voire toutes les heures ! Ce qu'il y a derrière devrait être transparent de nos jours.
L'équilibrage sur 400 machines entre les incrémentales et les complètes devrait être transparent. En cas d'arrêt du serveur plus de 7 jours, c'est un peu chiant… (surtout avec ma méthode de découper un serveur en petit morceau. Je m'en suis sortis en triant de manière aléatoire le fichier hosts car backuppc prends les machines dans l'ordre).
…
Voila ce qui me viens de tête. Sur des partitions de plus de 5To que je ne peux découper, j'utilise rdiff-backup qui va bien plus vite mais a d'autres défaut…
[^] # Re: Autre solution
Posté par Sytoka Modon (site web personnel) . En réponse au journal Le principe KISS appliqué à la gestion des sauvegardes.. Évalué à 4.
Pour les clients sous Windows, c'est faible. La méthode smb est lente, celle par rsync pas idéale et moisn rapide que pour un Linux. Pas de support du shadow copy de Windows. Un client windows serait je pense une bonne chose.
Backuppc a des soucis si la taille des données sur un poste sont trop grosse et puis la restauration se fait sans gestion des droits. Du coup, j'ai fait une moulinette qui à partir d'un fichier YAML génère autant de fichier pour backuppc qu'il y a d'utilisateur. Ainsi chaque utilisateur peut avoir accès a sa seule sauvegarde. J'ai ainsi des machines ayant plus de 1500 fichiers de conf chacune ! backuppc s'en sors très bien mais si on limite a 5 sauvegarde parallèles, il ne voit pas qu'en pratique, il sauve 5 fois la même machine physique mais des dossiers différents. On pourrait avoir un paramètre qui limite le nombre de rsync sur les machines physiques.
Pour info, mon script YAML me récupère via une requête rsync la liste des sous dossier des home, interroge le LDAP pour savoir si le compte associé est actif et génère alors le fichier de conf. Ainsi, le backup s'arrête tout seul lorsque les personnes partent !
Il y a des batailles pour savoir s'il vaut mieux du push ou du pull ! Moi, je n'aime pas que tous mes clients puissent lancer eux-mêmes leur sauvegardes et donc écrire sur le serveur. Cependant, si une personne est chez elle, plus de backup… Je pense que cette architecture est périmé. Ni push, ni pull sont bon à mon avis.
Il faudrait un agent sur le poste qui fait acte de présence sur le serveur en donnant son nom (type XMPP) et ouvrirait un port en retour via le tunnel ainsi crée. Le serveur central ferait alors quand il le décide une copie de backup en utilisant le tunnel ouvert par le client. Ainsi, le serveur pourrait faire un backup d'une machine située n'importe ou dans le monde.
Rsync, c'est bien mais on voit bien sur des très grosses partitions que la phase initiale est longue. Il faudrait pouvoir faire cela sur un snapshot LVM qui ne duplique pas les inode mais ne conserve que la trace des block modifiés (j'ai vu une fois une personne qui avait fait un patch la dessus). Le backup serait alors bien plus rapide. Autre solution, utiliser lsyncd pour conserver la liste sur le client des fichiers modifiés entre deux sauvegardes. On devrait pouvoir aller encore beaucoup plus vite.
Je pense que la notion de backup incrémentale et complète est complètement dépassé lorsqu'on travaille sur disque. On ne veux voir que des complètes tous les jours, voire toutes les heures ! Ce qu'il y a derrière devrait être transparent de nos jours.
L'équilibrage sur 400 machines entre les incrémentales et les complètes devrait être transparent. En cas d'arrêt du serveur plus de 7 jours, c'est un peu chiant… (surtout avec ma méthode de découper un serveur en petit morceau. Je m'en suis sortis en triant de manière aléatoire le fichier hosts car backuppc prends les machines dans l'ordre).
…
Voila ce qui me viens de tête. Sur des partitions de plus de 5To que je ne peux découper, j'utilise rdiff-backup qui va bien plus vite mais a d'autres défaut…