Sauvegarde avec BackupPC

Support Debian
#1

Bonjour,

J’utilise l’outils de sauvegarde BackupPc pour la sauvegarde de mes serveurs. Cependant, depuis quelque temps, j’ai une sauvegarde de serveur qui ne se termine plus, il faut ke je l’arrête à la main et de ce fait elle n’est pas utilisable.

La sauvegarde reste bloqué sur le /var de mon serveur.
J’ai exclu tous les fichiers de type socket qui étaient source de probléme mais la sauvegarde ne se finalise toujours pas. ( l’exclusion de fichier est possible en indiquant quels sont les fichiers qu’on ne ve pas sauvegarder dans le fichier de configuration config.pl)

Est ce que quelqu’un à une petite idée ?

#2

Ca serait bien que tu saches précisément ou ça bloque.
AMA, tu devrais exclure /var/lock, /var/tmp, /var/cache et /var/run qui ne contiennent rien d’utile à la reinstall, et où il y a des chances que certains fichiers soient verrouillés.
As tu installé quelquechose en particulier (je pense à apt-index-watcher, apt-watch ou cron-apt) au moment ou ça s’est mis à bloquer ?

#3

Bonjour,

Non j’ai rien d’installé de particulier.
Je vais essayé d’exclure les dossiers que tu m’as indiqué, sachant qu’il faut le faire dans des périodes creuses pour éviter les foudres des clients.
De plus, je doit être maudit, une autre erreur sur un autre serveur vient de faire son apparition.

La malchance continue…

Merci de votre aide

#4

pour ton deuxiême problême:
osdir.com/ml/sysutils.backup.bac … 00136.html
dit:[quote]You’re probably running out of memory and/or disk space[/quote]

#5

Re bonjour,

Je viens de vérifier l’espace disque du serveur de sauvegarde, et il reste de la place pour faire la sauvegarde.

Plus de détails sur l’erreur.

Remote[1]: received request to transfer non-regular file: 17 [sender] Remote[1]: rsync error: protocol incompatibility (code 2) at sender.c(214) [sender=2.6.9] Can't write 34102 bytes to socket Read EOF: Connexion ré-initialisée par le correspondant finish: removing in-process file lib/cyrus/proc/10248 [ 1 lignes sautées ] Child is aborting Done: 41 files, 374 bytes Got fatal error during xfer (aborted by signal=PIPE) Backup aborted by user signal

++

#6

Et la mêmoire ? (à vérifier avec free).

#7

Et au fait, je ne connais pas trop backupPC, mais ce n’est pas le serveur de sauvegarde qui fait le backup, mais le serveur que tu sauvegardes, non ? C’est là qu’il faut vérifier l’espace disque et la RAM. Et c’est je pense la place dans /tmp qu’il faut y vérifier.

#8

Re bonjour,

Qu’est ce que tu veux dire par là ?

J’ai un serveur de sauvegarde avec BackupPc d’installé et les sauvegardes sont stockées sur ce serveur. Lors d’une sauvegarde c’est une simple copie de fichiers en ssh avec rsync.

Au niveau de la RAM.

Pour le serveur de sauvegarde.
total used free shared buffers cached Mem: 1036804 1010532 26272

Pour le serveur sauvegardé.
total used free shared buffers cached Mem: 3116696 1913092 1203604 0 592580 867576

#9

Je veux dire que c’est sur la machine qui fait le rsync qu’il faut vérifier l’espace disque, ainsi que la RAM, le tout pendant le rsync.

Par ailleurs, un détail, même si tu as de la RAM, il est fortement conseillé d’installer un swap sur tes machines, l’un n’empêche pas l’autre: si tu as un pic de charge, ça te donne de la marge avant le crash, et les processus peu sollicités ou les pages inutilisées peuvent être swappés pour libèrer des buffers pour la gestion des disques, ce qui améliore les performances.
Un peu de doc là dessus:
linux.com/feature/121916

#10

Suite aux différents postes, j’ai vérifier la configuration des server=urs en question, et il y a suffisament d’espace disque, de ram et de swap.

Ensuite, j’ai lancé une sauvegarde pour observer le comportement des machines, et donc la RAM n’est jamais utilisé complétement et si cela arrive ça swap.

Je suis dans le flou total. :cry:

#11

Petite information supplémentaire, j’ai lancé une sauvegarde du serveur qui me pose probléme. Lorsque celle-ci arrive sur le /var backupPc prend 99.9% du cpu (vérification avec top).

…

#12

Ensuite, j’ai lancé une sauvegarde pour observer le comportement des machines, et donc la RAM n’est jamais utilisé complétement et si cela arrive ça swap.

Je suis dans le flou total. :cry:[/quote] Un peu d’info générale sur ton pb:
osdir.com/ml/sysutils.backup.bac … 00137.html
il semble qu’il faille retester que la connection ssh fonctionne bien.

#13

Bonjour,
Je suis confronté au même problème. As tu trouvé la solution a cela ?
merci

#14

J’ai l’impression que vous avez configuré votre sauvegarde d’une manière un peu originale. Que contient le répertoire /var backupPc ?
Je veux dire sur le serveur à sauvegarder, pourquoi ce répertoire ?

Si c’est un montage NFS, exporté depuis le serveur de sauvegarde, on a une jolie boucle de récursion.

D’une manière générale, je préconise pour un serveur d’avoir un /var dans une partition ou un volume logique séparé. A moins d’avoir des trucs du genre /var/lib/lxc ou autre, j’ai des doutes sur la pertinence de sauvegarder /var.

Pouvez-vous regarder les tailles des sous-répertoires de /var que vous sauvegardez ? sudo du -m -s /var/*

Cordialement,
Regards,
Mit freundlichen Grüssen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime

« L’arbre tombe toujours du côté où il penche. »
Proverbe français

#15

Bonjour. Je déterre ce post car ayant rencontré le même problème, je pense qu’y ajouter un début de solution peut aider ceux qui comme moi arrivent ici après une recherche google.

Pour ma part, un dossier spécifié dans le Xfer comportait une faute de frappe, donc il n’existait pas.
après un Time out, le process rsync disparaissait de la machine sauvegardée. puis message d’erreur (aborted by signal=PIPE) sur backuppc.

l’arbre cachait la forêt.

voilà.

Au cœur de Linux il y a un noyau. Au cœur de Windows, on trouve des pépins…