TetaTricks/chap/backups.tex

45 lines
1.7 KiB
TeX
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

\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 dexé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) ?
% ===============================================================
\section{rsync}\index{rsync}
\index{XXX}
\textsl{A fast, versatile, remote (and local) file-copying tool.}
% ===============================================================