Aurais tu quelques ressources à ce sujet stp ?
Etant en pleine gestation de DRP, et utilisant bacula pour la gestion de nos backups, cela m’intéresse au plus au point !
Non c'est juste ce que je retire de mon experience.
Quand tes backups te servent sans arrêt pour faire des restaurations partielles ou complètes (Bare Metal), bacula s'avère d'une lenteur exaspérante par rapport à du rsync / snapshot. Le temps qu'il élabore la liste des fichiers, que tu sélectionne ceux qui sont concernés, ton rsync est déjà en train de transferer.
Par ailleurs :
les gros fichiers type bande sont beaucoup plus faciles à corrompre que la tonne de petit fichiers de ton rsync.
la base de données est un goulet d'étranglement infernal. Tu passes ton temps à tuner le serveur de bdd et rajouter de la ram.
En cas de perte de le base tu en as pour des jours à tout récuperer …
Difficile de vérifier la présence des backups avant d'en avoir besoin.
De temps à autres, des erreurs inexplicables rendant les backups inexploitables.
Bref pour moi rien que la structure séquentielle du stockage et la dépendance en un service tiers (base de données) rendent impossible son utilisation en production. Mais le contexte est bien particulier :
- plusieurs centaines de serveurs
- du web et des mails (plein de petit fichiers)
- la plupart des utilisateurs qui tapent directement sur la prod
- Une GTR qui prévoie la restauration des données.
- Peu de redondance (beaucoup d'utilisateurs ont un et un seul serveur).
Ceci dit bacula est un bon produit. Il offre une grande liberté de configuration, une bonne gestion centralisée (mais attention avec le volume il faut de très grosses machines), une interface agréable. Mais il n'est adapté qu'à des environnements calme, bien procédurés et structuré. Bref à la place d'un Amanda ou d'un soft proprio c'est un bon candidat.
[^] # Re: Merci
Posté par Joris Dedieu (site web personnel) . En réponse au journal Le principe KISS appliqué à la gestion des sauvegardes.. Évalué à 6.
Non c'est juste ce que je retire de mon experience.
Quand tes backups te servent sans arrêt pour faire des restaurations partielles ou complètes (Bare Metal), bacula s'avère d'une lenteur exaspérante par rapport à du rsync / snapshot. Le temps qu'il élabore la liste des fichiers, que tu sélectionne ceux qui sont concernés, ton rsync est déjà en train de transferer.
Par ailleurs :
les gros fichiers type bande sont beaucoup plus faciles à corrompre que la tonne de petit fichiers de ton rsync.
la base de données est un goulet d'étranglement infernal. Tu passes ton temps à tuner le serveur de bdd et rajouter de la ram.
En cas de perte de le base tu en as pour des jours à tout récuperer …
Difficile de vérifier la présence des backups avant d'en avoir besoin.
De temps à autres, des erreurs inexplicables rendant les backups inexploitables.
Bref pour moi rien que la structure séquentielle du stockage et la dépendance en un service tiers (base de données) rendent impossible son utilisation en production. Mais le contexte est bien particulier :
- plusieurs centaines de serveurs
- du web et des mails (plein de petit fichiers)
- la plupart des utilisateurs qui tapent directement sur la prod
- Une GTR qui prévoie la restauration des données.
- Peu de redondance (beaucoup d'utilisateurs ont un et un seul serveur).
Ceci dit bacula est un bon produit. Il offre une grande liberté de configuration, une bonne gestion centralisée (mais attention avec le volume il faut de très grosses machines), une interface agréable. Mais il n'est adapté qu'à des environnements calme, bien procédurés et structuré. Bref à la place d'un Amanda ou d'un soft proprio c'est un bon candidat.