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.
 
 
 
 
 
 

56 lines
2.2 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) ?
% ===============================================================
\section{rsync}\index{rsync}
\index{XXX}
\textsl{A fast, versatile, remote (and local) file-copying tool.}
% ===============================================================
\section{Divers}
https://changelog.complete.org/archives/10160-how-why-to-use-airgapped-backups
Perhaps surprisingly, \texttt{tar} in listed incremental mode can solve this
problem for non-ZFS users. It will keep a local cache of the state
of the filesystem as of the time of the last run of tar, and can
generate new tarballs that reflect the changes since the previous
run (even deletions). This can achieve a similar result to the ZFS
send/receive, though in a much less elegant way.