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
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. |
|
|
|
|