Mon besoin :
* Je veux faire des sauvegardes incrémentales, avec un historique, et de façon complètement transparente (je ne veux pas surveiller en continu, je ne veux pas le lancer manuellement). Sur ce point burp fonctionne parfaitement. En cas de besoin burp-ui est là pour fouiller dans l'historique et voir si tout se passe bien.
* Je veux également faire faire une sauvegarde externalisée. Le principe que j'utilise : Je copie tout sur un disque dur USB que je dépose régulièrement dans la famille en rotation avec un second disque. J'ai toujours un disque à la maison et le second dans la famille. Je fais une rotation toutes les semaines.
Burp fournit un script qui devrait répondre à ton besoin. Je n'utilise pour éxternaliser mes sauvegardes en réseau, mais il doit être modifiable pour répondre à un besoin local.
Regarde dans /etc/burp/offsite-backup (ou ici).
C'est un script basé sur rsync avec gestion des hardlink. Ça devrait te permettre d'éviter de recopier tous tes backups à chaque fois.
Là c'est bien au niveau de l'interface graphique Burp-UI : L'affichage est globalement rapide sauf lors de l'affichage des fichiers. Lorsque je veux afficher les fichiers d'une sauvegarde il faut une dizaine de secondes pour afficher la page (ie : http://server:8000/client-browse/pc-xxx/12).
Ensuite je déplie le 1er nœud, il me faut 8 secondes pour afficher 3 répertoires. Puis une dizaine de secondes pour encore le noeud suivant, ... . Je me doute bien que derrière Burp-UI est tributaire de Burp et attend que ce dernier lise le manifest à chaque fois pour en filtrer la liste des fichiers.
Le fichier manifest de la dernière sauvegarde fait 16M gzippé et 119M dégzippé.
Burp-UI ajoute forcément une petite latence puisqu'il doit parser le retour de Burp afin de générer un document JSON, mais Burp doit lui aussi reparser son Manifest à chaque fois. Avec Burp2 les performances ont été améliorées avec l'ajout d'un cache (la conséquence c'est une consommation accrue de RAM). Et j'essaierai également d'ajouter un peu de cache par la suite. Mais dans tous les cas, la première exécution de l'instruction ne pourra pas être grandement améliorée, seuls les appels futurs le seront.
La 1ère fois que j'ai lancé bedup, ce dernier m'a sorti qu'il avait pu libérer quelques Go en dédupliquant certains fichiers. Du coup j'ai mis ce dernier dans une tâche cron. Par contre je n'ai aucune info sur l'efficacité de bedup dans le temps sauf à envoyer des mails à chaque cron (pas de joli graphe).
Même si je comprends bien que le programme est un peu à l'écart de burp, en tant qu'utilisateur je trouve ça dommage. A une époque j'avais utilisé backuppc. Ce dernier affiche quelques stats le nombre et la taille des fichiers dans le pool qui sont mutualisés.
Une telle fonctionnalité sous entendrait que Burp-UI serait en charge d'exécuter régulièrement bedup afin de tenir des statistiques. Avec Burp-UI j'ai voulu créer un programme simple dans son fonctionnement et dans son architecture. Cette demande apporterait beaucoup de complexité. De plus, je pense que bedup ne sera plus nécessaire avec Burp 2 puisque ce dernier procédera à de la déduplication en ligne.
Maintenant, si tu veux savoir la place théorique qu'occupe un backup sur le disque, il y a 2 reports qui peuvent t'aider dans Burp-UI. Le premier est le report "global" qui te donnera la place utilisée par tel ou tel client. Le second est le report "par client", qui peut t'indiquer le volume de données reçu par backup.
[^] # Re: Nouvel utilisateur de burp
Posté par Ziirish . En réponse au journal Burp-UI rend vos backups sexy. Évalué à 1.
Burp fournit un script qui devrait répondre à ton besoin. Je n'utilise pour éxternaliser mes sauvegardes en réseau, mais il doit être modifiable pour répondre à un besoin local.
Regarde dans /etc/burp/offsite-backup (ou ici).
C'est un script basé sur rsync avec gestion des hardlink. Ça devrait te permettre d'éviter de recopier tous tes backups à chaque fois.
Burp-UI ajoute forcément une petite latence puisqu'il doit parser le retour de Burp afin de générer un document JSON, mais Burp doit lui aussi reparser son Manifest à chaque fois. Avec Burp2 les performances ont été améliorées avec l'ajout d'un cache (la conséquence c'est une consommation accrue de RAM). Et j'essaierai également d'ajouter un peu de cache par la suite. Mais dans tous les cas, la première exécution de l'instruction ne pourra pas être grandement améliorée, seuls les appels futurs le seront.
Une telle fonctionnalité sous entendrait que Burp-UI serait en charge d'exécuter régulièrement bedup afin de tenir des statistiques. Avec Burp-UI j'ai voulu créer un programme simple dans son fonctionnement et dans son architecture. Cette demande apporterait beaucoup de complexité. De plus, je pense que bedup ne sera plus nécessaire avec Burp 2 puisque ce dernier procédera à de la déduplication en ligne.
Maintenant, si tu veux savoir la place théorique qu'occupe un backup sur le disque, il y a 2 reports qui peuvent t'aider dans Burp-UI. Le premier est le report "global" qui te donnera la place utilisée par tel ou tel client. Le second est le report "par client", qui peut t'indiquer le volume de données reçu par backup.