59 lines
2.3 KiB
TeX
59 lines
2.3 KiB
TeX
\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 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.
|
||
|