Une collection de notes diverses sur des trucs et astuces pour faire des choses avec un ordinateur...
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

36 lines
1.4 KiB

\chapter{Backups}
\index{backup}
% ===============================================================
\section{Geb...}
Si tu fais tous tes tgz d'un coup, puis les copie, tous d'un coup, les
copier juste après les avoir générés permettrait d'éviter de les relire
(et potentiellement de paralléliser)
Si les fichiers sont gros (trop pour tenir en ram), et changent tous
les jours, scp à la place d'rsync sera vraisemblablement plus performant
(pas de comparaison de checksum sources / destinations, d'autant plus
important si c'est sur des répertoires entiers)
Je suppose que tu n'utilises pas rsync -z ? Sinon, il ne sert
vraisemblablement à rien, les fichiers étant déjà compréssés.
Si tu gzip plusieurs Go à chaque fois, et a plusieurs cores, pigz
(https://zlib.net/pigz/) devrait etre plus performant que gzip (tu peux
le ln -s / dpkg --divert à la place de gzip), le gain est quasi linéaire
par rapport au nombre de cores.
gzip, comme pigz permettent de régler le niveau de compression.
Généralement diminuer celui-ci raisonnablement impacte peu la taille des
fichiers générés mais énormément les temps d’exécution (et peut être la
mémoire).
La réactivité de ton système s'en ressent elle si tu lances tes
scripts à coup de nice -n10 ( / -n15 / -n20 ) sans que cela augmente
trop les temps de backup ?
Quid de juste rsync sur ton serveur et faire les tgz à l'autre bout
(tu profiteras ainsi pleinement du coté incrémental d'rsync) ?