TetaTricks/chap/backups.tex

59 lines
2.3 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}
% https://blog.flozz.fr/2023/10/15/borgbackup-sauvegarde-sur-une-machine-distante-via-ssh/
% ===============================================================
\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.}
% ===============================================================
\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.