Utilitaire de sauvegarde Linux pour des sauvegardes incrémentielles
Je cherche un utilitaire de sauvegarde avec des sauvegardes incrémentielles, mais de manière plus compliquée.
J'ai essayé Rsync, mais cela ne semble pas être capable de faire ce que je veux, ou plus probablement, je ne sais pas comment faire ça.
C'est donc un exemple de ce que je veux réaliser avec elle. J'ai les fichiers suivants:
testdir
├── picture1
├── randomfile1
├── randomfile2
└── textfile1
Je souhaite exécuter l'utilitaire de sauvegarde et créer essentiellement une archive (ou une archive) de tous ces fichiers dans un répertoire différent:
$ mystery-command testdir/ testbak
testbak
└── 2020-02-16--05-10-45--testdir.tar
Maintenant, disons le lendemain, j'ajoute un fichier, de sorte que ma structure ressemble à:
testdir
├── picture1
├── randomfile1
├── randomfile2
├── randomfile3
└── textfile1
Maintenant, quand je gère le commandement mystérieux, je vais obtenir une autre butes pour ce jour-là:
$ mystery-command testdir/ testbak
testbak
├── 2020-02-16--05-10-45--testdir.tar
└── 2020-02-17--03-24-16--testdir.tar
Voici le kicker: je veux que l'utilitaire de sauvegarde détecte le fait que picture1, randomfile1, randomfile2 et textfile1 n'a pas été changé depuis la dernière sauvegarde et ne sauvegarde que les fichiers nouveaux/modifiés, ce qui est dans ce cas randomfile3, tel que:
tester@raspberrypi:~ $ tar -tf testbak/2020-02-16--05-10-45--testdir.tar
testdir/
testdir/randomfile1
testdir/textfile1
testdir/randomfile2
testdir/picture1
tester@raspberrypi:~ $ tar -tf testbak/2020-02-17--03-24-16--testdir.tar
testdir/randomfile3
Donc, comme un dernier exemple, disons le lendemain, j'ai changé textfile1, et ajouté picture2 et picture3:
$ mystery-command testdir/ testbak
testbak/
├── 2020-02-16--05-10-45--testdir.tar
├── 2020-02-17--03-24-16--testdir.tar
└── 2020-02-18--01-54-41--testdir.tar
tester@raspberrypi:~ $ tar -tf testbak/2020-02-16--05-10-45--testdir.tar
testdir/
testdir/randomfile1
testdir/textfile1
testdir/randomfile2
testdir/picture1
tester@raspberrypi:~ $ tar -tf testbak/2020-02-17--03-24-16--testdir.tar
testdir/randomfile3
tester@raspberrypi:~ $ tar -tf testbak/2020-02-18--01-54-41--testdir.tar
testdir/textfile1
testdir/picture2
testdir/picture3
Avec ce système, je sauverais de l'espace en sauvegardant uniquement les modifications incrémentielles entre chaque sauvegarde (avec évidemment la sauvegarde principale comportant tous les fichiers initiaux) et j'aurais des sauvegardes des changements incrémentiels, donc par exemple si j'ai fait un changement. Le deuxième jour et changé la même chose le jour 3, je peux toujours obtenir le fichier avec le changement de jour 2, mais avant le passage du jour 3.
Je pense que c'est un peu comme comment Github travaille :)
Je sais que je pourrais probablement créer un script qui exécute un diff, puis sélectionne les fichiers à sauvegarder en fonction du résultat (ou plus efficacement, obtenez simplement une somme de contrôle et comparez), mais je veux savoir s'il y a une utilité qui peut faire cela TAD plus facile :)
Bien que tar a un mode incrémentiel il y a quelques outils plus complets pour faire le travail:
Ils supportent non seulement les sauvegardes incrémentielles, il est facile de configurer un horaire sur lequel une sauvegarde complète doit être prise. Par exemple dans duplicity: duplicity --full-if-older-than 1M Assurer une sauvegarde complète. Ils prennent également en charge de retourner à l'heure à un fichier spécifique, avec un goudron simple, vous devrez passer par tous les fichiers incrémentiels jusqu'à l'avoir trouvé celui qui contient le bon fichier.
En outre, ils supportent le cryptage et le téléchargement dans une variété de backends (comme SFTP, Stockage Blob, etc.). Évidemment, si vous cryptez, n'oubliez pas de faire une bonne sauvegarde de vos clés à une sauvegarde secondaire!
Un autre aspect important est que vous pouvez vérifier l'intégrité de vos sauvegardes, vous garantissant que vous pouvez restaurer, par exemple en utilisant duplicity verify.
Je vous conseille négativement sur une stratégie de sauvegarde basée sur GIT. Les grandes restaurations prennent des moments significatifs.
J'ai essayé Rsync, mais cela ne semble pas être capable de faire ce que je veux, ou plus probablement, je ne sais pas comment faire ça.
Je sais que je pourrais probablement créer un script qui exécute un diff, puis sélectionne les fichiers à sauvegarder en fonction du résultat (ou plus efficacement, obtenez simplement une somme de contrôle et comparez), mais je veux savoir s'il y a une utilité qui peut faire cela TAD plus facile :)
rsync est précisément ce programme qui copie basé sur un diff. Par défaut, il se copie uniquement lorsqu'il y a une différence de temps ou de taille modifiée de dernière modification, mais elle peut même comparer par checksum avec -c.
Le problème ici est que vous êtes tar 'ing les sauvegardes. Cela devient plus facile si vous ne le faites pas. Je ne sais même pas pourquoi tu le fais. Cela pourrait avoir du sens si vous les comprimez, mais vous ne le faites même pas.
Le article Wikipedia pour les sauvegardes incrémentielles a un exemple de rsync commande qui va à peu près:
rsync -va \
--link-dest="$dst/2020-02-16--05-10-45--testdir/" \
"$src/testdir/" \
"$dst/2020-02-17--03-24-16--testdir/"
Ce qu'il fait, c'est aux fichiers hardlink de la sauvegarde précédente lorsqu'ils sont inchangés de la source. Il y a aussi --copy-dest si vous voulez qu'il copie à la place (il est toujours plus rapide lorsque $dst est une télécommande ou sur un lecteur plus rapide).
Si vous utilisez un système de fichiers avec des sous-volumes tels que BTRFS, vous pouvez également simplement instantané de la sauvegarde précédente avant que rsync'ing. Les instantanés sont instantanés et ne prennent pas de place supplémentaire [1].
btrfs subvolume snapshot \
"$dst/2020-02-16--05-10-45--testdir" \
"$dst/2020-02-17--03-24-16--testdir"
Ou si vous utilisez un système de fichiers qui prend en charge reflète, comme EXT4, vous pouvez également le faire. Les reflétes sont effectuées en faisant une nouvelle inode mais en faisant référence aux mêmes blocs que le fichier source, mettant en œuvre le support de vache. Il est toujours plus rapide que la copie régulière car elle ne lit pas et n'écrire pas les données, et elle ne prend pas aussi de l'espace supplémentaire [1].
cp --reflink -av \
"$dst/2020-02-16--05-10-45--testdir" \
"$dst/2020-02-17--03-24-16--testdir"
Quoi qu'il en soit, une fois que vous avez fait quelque chose comme ça, vous pouvez simplement faire un rsync pour copier les différences:
rsync -va \
"$src/testdir/" \
"$dst/2020-02-17--03-24-16--testdir/"
Cependant, vous voudrez peut-être ajouter --delete, ce qui ferait que RSYNC supprimerait des fichiers de la destination qui ne sont plus présents dans la source.
Une autre option utile est -i ou --itemize-changes. Il produit une sortie lisible succinct et lisible qui décrit les modifications apportées par RSYNC. J'ajoute normalement cette option et cette pipe comme:
rsync -Pai --delete \
"$src/testdir/" \
"$dst/2020-02-17--03-24-16--testdir/" \
|& tee -a "$dst/2020-02-17--03-24-16--testdir.log"
pour conserver l'enregistrement des modifications via facilement grep fichiers capables. Le |& est de faire pipeler les deux stdout et stardr.
Le -P est court pour --partial et --progress. --partial conserve les fichiers partiellement transférés, mais surtout --progress rapporte des progrès par fichier.
Comment cela se compare à l'archivage des changements avec goudron
Les solutions ci-dessus entraînent des annuaires qui semblent tout tenir. Même si c'est le cas, au total pour toute quantité/fréquence de sauvegarde, ils occuperaient autour du même espace que d'avoir des archives de goudron simples avec uniquement des changements. C'est à cause de la manière dont les hardlinks, reflent et les instantanés fonctionnent. L'utilisation de la bande passante lors de la création des sauvegardes serait également la même.
Les avantages sont:
- les sauvegardes sont faciles à restaurer avec RSYNC et plus rapidement, car RSYNC ne ferait que transférer les différences de la sauvegarde.
- ils sont plus simples de parcourir et de modifier si nécessaire.
- les suppressions de fichier peuvent être codées naturellement comme l'absence du fichier dans les nouvelles sauvegardes. Lorsque vous utilisez des archives de goudron, il faudrait recourir à des hacks, à supprimer un fichier
foo, marquez-lefoo.DELETEDou faire quelque chose de compliqué. Je n'ai jamais utilisé la duplicité par exemple, mais en regardant sa documentation, il semble que cela coode des suppressions en ajoutant un fichier vide du même nom dans le nouveau goudron et en maintenant la signature d'origine du fichier dans un fichier .Sigtar distinct. J'imagine que cela compare la signature d'origine avec celle d'un fichier vide à différencier entre une suppression de fichier et une modification d'un fichier vide réel.
Si l'on veut toujours configurer chaque sauvegarde, ce qui ne contient que les fichiers différents (ajoutés ou modifiés), on peut utiliser la solution --link-dest décrite ci-dessus, puis supprimez les lignes hardlinks en utilisant quelque chose comme ce qui suit:
find $new_backup -type f ! -links 1 -delete
[1] Strictement parlant, ils utilisent des espaces supplémentaires sous la forme de métadonnées en double, comme le nom de fichier et tel. Cependant, je pense que quiconque considérerait que l'insignifiant.
Et pourquoi n'envisagez-vous pas git lui-même?
La stratégie que vous décrivez, après une sauvegarde complète et progressive, a des complications lorsque vous continuez. Il est facile de faire des erreurs, et c'est peut Obtenez très inefficace, en fonction des modifications. Il devrait y avoir une sorte de rotation, c'est-à-dire de temps en temps, vous faites une nouvelle sauvegarde complète - et voulez-vous garder l'ancien ou non?
Compte tenu d'un Travailler dir "Testdir" contenant du fichier Projet (fichiers et sous-dialogres), git fait par défaut un caché .git subdir pour les données. Ce serait pour la locale, supplémentaire Contrôle de la version Caractéristiques. Pour la sauvegarde, vous pouvez l'archiver/le copier à un support ou à un clonage via le réseau.
Le Contrôle de révision Vous obtenez (sans demander) est un effet secondaire du stockage différentiel de GIT.
Vous pouvez laisser tout le fourrage/la ramification et ainsi de suite. Cela signifie que vous avez une branche appelée "maître".
Avant de pouvoir vous engager (écrire en réalité à l'archive GIT/Repo), vous devez configurer un utilisateur minimal pour le fichier de configuration. Ensuite, vous devriez d'abord apprendre et tester dans un subdir (peut-être TMPFS). Git est aussi délicat que le goudron, parfois.
Quoi qu'il en soit, comme un commentaire dit: la sauvegarde est facile, une partie difficile est la restauration.
Les inconvénients de GIT ne seraient que les petits frais généraux/overkills.
Les avantages sont: git pistes Noms de contenu et de fichier. Cela ne fait que sauver ce qui est nécessaire, sur la base d'un diff (pour les fichiers texte au moins).
Exemple
J'ai 3 fichiers dans un dir. Après git init, git add . et git commit J'ai un 260k .git dir.
Alors je cp -r .git /tmp/abpic.git (un bon endroit pour sauvegarder une sauvegarde :). I rm le 154k jpg, et aussi Changer fichier texte. Moi aussi rm -r .git.
]# ls
atext btext
]# git --git-dir=/tmp/abpic.git/ ls-files
atext
btext
pic154k.jpg
Avant de restaurer les fichiers, je peux obtenir les différences précises:
]# git --git-dir=/tmp/abpic.git/ status
On branch master
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: atext
deleted: pic154k.jpg
no changes added to commit (use "git add" and/or "git commit -a")
Ici, je veux suivre le git restore indice.
Après git --git-dir=/tmp/abpic.git/ restore \*:
]# ls -st
total 164
4 atext 156 pic154k.jpg 4 btext
Le JPEG est de retour, et le fichier texte btext a non été mis à jour (garde horodatage). Les modifications de atext sont écrasées.
Pour réunir le repo et le directeur (travail), vous pouvez simplement le copier.
]# cp -r /tmp/abpic.git/ .git
]# git status
On branch master
nothing to commit, working tree clean
Les fichiers de l'AIR actuel sont identiques à la .git archive (après le restore). De nouvelles modifications seront affichées et peuvent être ajoutées et engagées, sans aucune planification. Il vous suffit de le stocker à un autre support, à des fins de sauvegarde.
Une fois qu'un fichier est modifié, vous pouvez utiliser status ou diff:
]# echo more >>btext
]# git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: btext
no changes added to commit (use "git add" and/or "git commit -a")
]# git diff
diff --git a/btext b/btext
index 96b5d76..a4a6c5b 100644
--- a/btext
+++ b/btext
@@ -1,2 +1,3 @@
This is file b
second line
+more
#]
Et juste comme git sait sur "+ plus" dans le fichier "BTEXT", il ne stockera également que cette ligne progressivement.
Après git add . (ou git add btext) Les commutateurs de commande status de rouge au vert et le commit vous donne les informations.
]# git add .
]# git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: btext
]# git commit -m 'btext: more'
[master fad0453] btext: more
1 file changed, 1 insertion(+)
Et vous pouvez vraiment obtenir au contenu, d'une manière ou d'une autre:
]# git ls-tree @
100644 blob 321e55a5dc61e25fe34e7c79f388101bd1ae4bbf atext
100644 blob a4a6c5bd3359d84705e5fd01884caa8abd1736d0 btext
100644 blob 2d550ffe96aa4347e465109831ac52b7897b9f0d pic154k.jpg
Et puis les 4 premiers chiffres de hachage hexagonales
]# git cat-file blob a4a6
This is file b
second line
more
Pour aller de retour à temps par un commettre c'est:
]# git ls-tree @^
100644 blob 321e55a5dc61e25fe34e7c79f388101bd1ae4bbf atext
100644 blob 96b5d76c5ee3ccb7e02be421e21c4fb8b96ca2f0 btext
100644 blob 2d550ffe96aa4347e465109831ac52b7897b9f0d pic154k.jpg
]# git cat-file blob 96b5
This is file b
second line
le blob de BTEXT a un hachage différent avant la dernière commission, les autres ont la même chose.
Un aperçu serait:
]# git log
commit fad04538f7f8ddae1f630b648d1fe85c1fafa1b4 (HEAD -> master)
Author: Your Name <[email protected]>
Date: Sun Feb 16 10:51:51 2020 +0000
btext: more
commit 0bfc1837e20988f1b80f8b7070c5cdd2de346dc7
Author: Your Name <[email protected]>
Date: Sun Feb 16 08:45:16 2020 +0000
added 3 files with 'add .'
Au lieu de fichiers goudronnés chronologiques manuellement, vous vous engagez avec un message et une date (et un auteur). Logiquement attachées à ces commits sont les listes de fichiers et le contenu.
Simple git est de 20% plus compliqué que tar, mais vous obtenez une fonctionnalité de 50% de plus en plus.
Je voulais faire la troisième modification de l'OP: modifier un fichier plus deux nouveaux fichiers "image". Je l'ai fait, mais maintenant j'ai:
]# git log
commit deca7be7de8571a222d9fb9c0d1287e1d4d3160c (HEAD -> master)
Author: Your Name <[email protected]>
Date: Sun Feb 16 17:56:18 2020 +0000
didn't add the pics before :(
commit b0355a07476c8d8103ce937ddc372575f0fb8ebf
Author: Your Name <[email protected]>
Date: Sun Feb 16 17:54:03 2020 +0000
Two new picture files
Had to change btext...
commit fad04538f7f8ddae1f630b648d1fe85c1fafa1b4
Author: Your Name <[email protected]>
Date: Sun Feb 16 10:51:51 2020 +0000
btext: more
commit 0bfc1837e20988f1b80f8b7070c5cdd2de346dc7
Author: Your Name <[email protected]>
Date: Sun Feb 16 08:45:16 2020 +0000
added 3 files with 'add .'
]#
Alors, qu'est-ce que votre nom a fait exactement, dans ses deux commits, peu de temps avant 18 heures?
Les détails de la dernière validation sont:
]# git show
commit deca7be7de8571a222d9fb9c0d1287e1d4d3160c (HEAD -> master)
Author: Your Name <[email protected]>
Date: Sun Feb 16 17:56:18 2020 +0000
didn't add the pics before :(
diff --git a/picture2 b/picture2
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/picture2
@@ -0,0 +1 @@
+1
diff --git a/picture3 b/picture3
new file mode 100644
index 0000000..0cfbf08
--- /dev/null
+++ b/picture3
@@ -0,0 +1 @@
+2
]#
Et pour vérifier la deuxième-to----------------------Dernière commit, dont le message annonce deux images:
]# git show @^
commit b0355a07476c8d8103ce937ddc372575f0fb8ebf
Author: Your Name <[email protected]>
Date: Sun Feb 16 17:54:03 2020 +0000
Two new picture files
Had to change btext...
diff --git a/btext b/btext
index a4a6c5b..de7291e 100644
--- a/btext
+++ b/btext
@@ -1,3 +1 @@
-This is file b
-second line
-more
+Completely changed file b
]#
C'est arrivé parce que j'ai essayé git commit -a à raccourci git add ., et les deux fichiers étaient NOUVEAU (non traqui). Il a montré en rouge avec git status, mais comme je dis que Git n'est pas moins délicat que le goudron, ou UNIX.
"Votre DEBUTANTE saisit simplement ce dont vous avez besoin, mais je sais ce que vous voulez" (ou l'inverse. Point est que ce n'est pas toujours le même)
Je recommande star pour des sauvegardes incrémentielles, puisque star a été vérifiée pour supporter de manière fiable les décharges incrémentielles et Restaure. Ce dernier est ce qui ne fonctionne pas avec GNU Tar lorsque vous renommez des annuaires, même s'il est annoncé depuis 28 ans.
Veuillez lire la page star manuel à - http://schilytools.sourceforge.net/man/man1/star.1.html
La section sur les sauvegardes incrémentielles commence actuellement à la page 53.
Pour télécharger la source, obtenez la tabasse SchilyTools à partir de http://sourceforge.net/projects/schilyTools/files/
Vérifiez est-il possible d'utiliser goudron pour des sauvegardes complètes du système? Pour une vérification du GNU bug tag.
Je vous recommanderais de regarder - Borg Backup .
Cela gérera les sauvegardes qui:
Sont dédupliqués. Cela en fait indirectement des sauvegardes différentielles, mais présente plus d'avantages:
- Il gérera plusieurs copies du même fichier
- Ou même des mêmes blocs dans différents fichiers
- Aidera avec les fichiers qui cultivent (comme des journaux)
- Aidera avec les fichiers renommés (comme des journaux dans certaines configurations de rotation)
Sont compressés
- Peut être monté comme un système de fichiers distant régulier (vous pouvez monter n'importe laquelle des sauvegardes précédentes)
Il gérera la taille des anciennes sauvegardes en utilisant des règles telles que "Gardez une sauvegarde quotidienne pendant une semaine, une sauvegarde hebdomadaire pendant un mois, une sauvegarde mensuelle pour une année"
C'est vraiment facile à configurer et à utiliser.
Vous pouvez essayer BACKUPPC .
Il permet des sauvegardes incrémentielles, vous pouvez décider de la fréquence de les faire, combien de personnes à conserver et lorsque vous les regardez, vous pouvez les voir consolidés ou simplement la sauvegarde incrémentale. Il déduit également les fichiers complets, doivent-ils être présents dans différentes sauvegardes des mêmes hôtes ou différents.
Il est probablement déjà emballé pour votre distribution.
Jetez un coup d'œil à RESTIC . Il effectue des sauvegardes incrémentielles utilisant un algorithme appelé déduplication. Il est également très facile d'utiliser si c'est génial pour un utilisateur de ligne de commande débutant ou avancé.
Ce n'est pas exactement ce que vous demandez, car il n'utilise pas de goudron. Mais il utilise RSYNC, et cela a très bien fonctionné pour moi. Sur les capacités que j'aime vraiment, c'est la capacité de laisser tomber des points de restauration incrémentiels au fil du temps sans perdre de points avant ou après celui que je tombe. Cela me permet, par exemple, d'avoir des sauvegardes quotidiennes pour les 2 dernières semaines, puis de la fin de ces deux semaines pour avoir 2 semaines afin qu'ils soient hebdomadaires pendant quelques mois, puis finissent de plus en plus jusqu'à ce qu'ils soient tous les mois pendant un quart ou deux , puis minez ceux qui sont à peu près trimestriellement au cours de la période d'années. J'ai un python Script que je peux partager cela peut les élaguer automatiquement si vous le souhaitez. (Évidemment, il est livré sans garantie car il ne faut que laisser un ordinateur supprimer automatiquement les sauvegardes sonne un peu effrayant.)
Ce que je fais, c'est utiliser un piscine et un système de fichiers ZFS pour stocker des sauvegardes. Avec le système de fichiers ZFS, qui est (heureusement!) Maintenant utilisable sous Linux, vous pouvez prendre des instantanés. Lorsque vous écrivez à un système de fichiers qui a été instantané, il écrit (intelligemment) une nouvelle version de seuls blocs modifiés, ce qui en fait une sauvegarde incrémentielle. Plus facilement est que tous vos instantanés peuvent être montés comme un système de fichiers UNIX complète (en lecture seule), que vous pouvez utiliser tous vos outils normaux pour regarder et copier. Vous voulez voir ce que ce fichier ressemblait il y a 2 mois? Juste CD dans le bon dossier et utiliser moins ou vim ou quoi que ce soit pour le regarder. Voulez-vous voir quand un (piraté) wordpress Installez que vous souteniez votre sauvegarde est sorti des rails? Faites juste un grep pour une marque d'identification avec quelque chose comme grep -in /zfsbackup/computername/.zfs/snapshots/*/var/www/html/wp-config.php" "somebadstring"
Vous pouvez même utiliser le système LUKS de Linux pour effectuer un cryptage de disque, puis présentez le périphérique mappé en tant que "lecteurs" à ZFS, vous donnant une sauvegarde cryptée.
Si vous avez besoin de migrer vos sauvegardes vers un nouveau lecteur, vous pouvez utiliser ZFS Envoyer et recevoir pour déplacer tout le système de fichiers.
Cela a été un an ou deux depuis que je l'ai mis en place (je continue de continuer à ajouter des sauvegardes incrémentielles et je n'ai pas eu besoin de mettre à niveau mon lecteur de sauvegarde pendant un moment), de sorte que celles-ci seront des instructions approfondies. Ours avec moi, ou mieux encore, éditez-les.
Tout d'abord, assurez-vous d'avoir ZFS, RSYNC et, si vous souhaitez chiffrer vos sauvegardes, les outils LUKS installés.
Tout d'abord, créez une disposition de partition que vous pourriez souhaiter sur votre lecteur de sauvegarde. (Vous voudrez peut-être créer une petite partition non cryptée qui a des scripts pour exécuter la sauvegarde.)
Ensuite, si vous souhaitez cryptage de disque, chiffrer la partition avec LUKS (Exemple suppose un lecteur de sauvegarde de/dev/sde et une partition/dev/sde2 depuis/dev/sde1 est probablement des scripts):
Sudo cryptsetup luksFormat /dev/sde2
(Mettez une belle phrase secrète).
Si vous faites du cryptage sur disque, vous devez maintenant ouvrir le volume:
Sudo cryptsetup luksOpen /dev/sde2 zfsbackuppart1
(Maintenant qu'une version non cryptée du dispositif brut doit être disponible (mappée) à/dev/mapper/zfsbackuppart1).
Maintenant, créez-vous une piscine ZFS (groupe de données de contenant), plusieurs lecteurs/périphériques peuvent être utilisés pour le raid si vous le souhaitez):
Sudo zpool create zfsbackup /dev/mapper/zfsbackuppart1
Cela créera un pool ZFS nommé "ZFSBackup".
Maintenant, créez un système de fichiers pour chaque machine que vous sauvegardez:
Sudo zfs create zfsbackup/machinename
Et créer un dossier pour chaque partition que vous souhaitez sauvegarder de la machine source:
Sudo mkdir /zfsbackup/machinename/slash/
Sudo mkdir /zfsbackup/machinename/boot/
Ensuite, utilisez rsync pour copier des fichiers là-bas:
Sudo rsync -avx --numeric-ids --exclude .gvfs / /zfsbackup/machinename/slash/ --delete-after
Sudo rsync -avx --numeric-ids --exclude .gvfs /boot/ /zfsbackup/machinename/boot/ --delete-after
Prenez un instantané:
zfs snapshot zfsbackup/machinename@`date +%F_%T`
Pour débrancher le lecteur lorsque vous avez terminé:
zpool export zfsbackup
# Next line, for each underlying encrypted block device, if using encryption:
cryptsetup luksClose zfsbackuppart1
Et pour le mettre en place lorsque vous prenez une autre sauvegarde à l'avenir, avant les commandes RSYNC ci-dessus:
cryptsetup luksOpen /dev/sde2 zfsbackuppart1
zpool import zfsbackup
Faites-moi savoir si vous avez besoin de plus d'informations sur cette approche ou si vous êtes intéressé par un script pour les sauvegardes de pointe, car ils sont plus loin dans le temps.
Et oui, vous pouvez sauvegarder un système entier de cette façon - il vous suffit de créer des partitions/des systèmes de fichiers (qui ne doivent pas correspondre à la mise en page d'origine - un excellent moyen de migrer des choses!), Tweak/etc/fstab, et installer GRUB & l'avez-le à résoudre/reconstituer le GRUB config.
Une possibilité est Amanda, l'archiveur de disques de réseau automatique de Maryland avancé , qui parmi des charges d'autres fonctionnalités, prenez également en charge des sauvegardes incrémentielles.
La très ancienne commande bsd rdump ferait des niveaux de sauvegarde. Niveau 0 a soutenu l'ensemble du système de fichiers. Niveau 1 Sauvegarde de ce qui a changé depuis le niveau zéro, le niveau 2 ferait toutes les sauvegardes depuis le niveau 1. Pour vraiment les fichiers nécessaires zéro à appliquer sur le système de fichiers, puis le niveau 2, suivi de 3 (si utilisé). RDump a le malheur de l'écriture sur une bande ...
Le script de shell suivant fera ce que vous voulez utiliser GARE, Trouver et Egrep. Il a utilisé le drapeau -Neewer de la recherche comparant "plus récent" contre une "touche" Ed créé lorsque le script a été exécuté. Le script a été exécuté sur un Solaris 4.3BSD des années 1990 pour copier des fichiers source entre une machine de développement UNIX et des ordinateurs portables en utilisant Kermit.
Le script est plutôt fragile car si le script "touche" es le fichier d'heure de mise à jour et que le goudron échoue, le fichier temporel doit alors être recréé. Le fichier tar a le nom de la date + heure + minute + seconde. `#!/bin/sh -vx
echo finding newer files than update ...
cd /home/programs/gis
HOME_LOC=/home/programs/gis/
TAR_FILE=${HOME_LOC}stage/u`date +%m%d%H%M`.tar.bz2
#run find one using the -o (or) syntax
(
find . -newer ${HOME_LOC}/update \
\( -name '*.[hcsf]' -o -name '*.asm' \
-o -name '*.ma*' -o -name '*.cpp' \
-o -name '*.msg' -o -name '*.hpp' \
-o -name 'Makefile' -o -name '*.inl' \
-o -name 'grid*.*' -o -name '*.glb' \) \
-print ) | \
egrep -v 'SCCS|stage|local.h' | tee /usr/tmp/x.$$
echo copying files:
tar -cjhf ${TAR_FILE} `cat /usr/tmp/x.$$`
# rm /usr/tmp/x.$$
if test -r ${TAR_FILE}
then
touch ${HOME_LOC}/update
fi
`
Pensez à utiliser BUP :
- Pas besoin de s'inquiéter de la distinction de sauvegardes complètes/incrémentielles/décrémentales.
- Les sauvegardes sont aussi rapides que les sauvegardes incrémentielles
- Les restaurations sont aussi simples que des sauvegardes complètes
- Basé sur le format de stockage de GIT , étendu pour supporter de très grandes sauvegardes
- Terminez la déduplication entre les fichiers (et les parties de fichiers), versions et branches. Ceci est particulièrement bénéfique si vous devez sauvegarder plus d'une machine ou plusieurs VM instantanés.
- Peut ajouter des codes de correction d'erreur à l'archive à l'aide de Par2
- Accès facile à l'ensemble de l'arborescence de sauvegarde, avec des commandes directes ou en montrant l'arborescence sous forme de système de fichiers
Les mises en garde que j'ai trouvées jusqu'à présent:
- Toujours jeune et en phase alpha (version actuelle est 0.x)
- Besoins Python 2, donc ce n'est pas exactement léger en termes de dépendances
buputilise le verrouillage du fichier dans le dossier d'archivage. Cela signifie que l'hébergement du système de fichiers l'archive doit prendre en charge le verrouillage du fichier. Cela pourrait être un problème avec SMB actions. (NFS fonctionne cependant.)- Les sauvegardes vers ou depuis des hôtes distants (via
ssh) nécessitentbupà installer là-bas. - Pour vos noms de sauvegarde (qui sont des branches git), vous pourriez être tenté d'utiliser quelque chose contenant des barres obliques (
/). Ce n'est pas un problème pourgit, maisbup lsest confondu par ceux-ci, alors ne le faites pas. (Vous pouvez modifier le nom de la succursale avec ungit branch -mcommande si vous êtes mordu par ça.)
En plus de toutes les excellentes solutions fournies ci-dessus, j'ai une approche supplémentaire. Puisque vous n'avez pas mentionné le système de fichiers que vous utilisez, je suppose que vous n'utilisez pas ZFS ou BTRFS. Ces systèmes de fichiers ont des capacités intégrées pour effectuer des instantanés qui ne sont pas des copies de l'ensemble du système de fichiers, mais simplement des incréments. Une approche typique serait la suivante:
- Créez un système de fichiers ZFS/BTRFS.
- Localisez toutes vos données (qui doivent être suivies) sur ce système de fichiers.
- Configurer des instantanés
- Configurez la rétention/la rotation d'instantané (sinon, vos instantanés continueront à cultiver et à occuper un espace disque).
Par exemple, si vous configurez une rétention de 5 jours, vous pouvez remonter jusqu'à 5 jours à temps.
On dirait que vous essayez de faire des sauvegardes différentielles. J'ai utilisé 7zip (comme je devais aussi compresser et chiffrer) dans le passé pour cela. De nombreux tutoriels sont disponibles, par exemple celui-ci .
Recherchez "Mike's Handy File System System Snapshot Utility". Il s'agit essentiellement d'un script de commodité qui enveloppe rsync Pour faire tourner des sauvegardes incrémentielles en rotation d'un répertoire. Il minimisera l'utilisation de la mémoire en reliant les sauvegardes incrémentielles antérieures pour tous les fichiers qui n'ont pas changé.
Voir Sauvegardes de style instantané automatisées simples avec Linux et RSYNC pour une introduction complète avec une explication de la façon dont cela fonctionne.