storeBackup, l'outil de sauvegarde non conventionnel

ArticleCategory: [Choose a category, translators: do not translate this, see list below for available categories]

System Administration

AuthorImage:[Here we need a little image from you]

TranslationInfo:[Author + translation history. mailto: or http://homepage]

original in de Heinz-Josef Claes

de to en Jürgen Pohl
en to fr Iznogood

AboutTheAuthor:[A small biography about the author]

The author prefers to not publish any picture of him online.

Abstract:[Here you write a little summary]

StoreBackup est destiné à l'utilisateur lambda qui ne possède pas nécessairement une sauvegarde à bandes mais un second disque dur ou un autre ordinateur. Il permet aussi, aux utilisateurs professionnels, un accès extrèmement rapide et confortable aux sauvegardes et de réaliser des économies sur le coût des bandes ainsi que sur les coûts administratifs.

Le stockage sur disques dur ou des périphériques identiques est une alternative ou une ressource additionnelle à la sauvegarde sur bandes. Le programme présenté ici est efficace et économise de la capacité de sauvegarde :

Les répertoires, incluant leur structure arborescente, peuvent être copiés vers une autre destination (i.e. /home => /var/bkup/2003.12.13_02.04.26). Les permissions des fichiers sont préservées, permettant aux utilisateurs d'accéder aux sauvegardes directement.
Le contenu des fichiers est comparé avec la sauvegarde existante pour s'assurer qu'il n'y ait qu'une sauvegarde pour chaque fichier, ce qui signifie que les fichiers avec un contenu identique n'existent qu'une fois physiquement dans la sauvegarde.
Les fichiers identiques sont reliés en dur et apparaissent dans la sauvegarde aux même endroits que ceux d'origine.
Les fichiers de sauvegarde sont compressés, excepté ceux marqués 'exclude'. La compression peut être complètement suprimée.
Les séries de sauvegardes, générée indépendement (i.e. depuis des machines différentes) peuvent faire référence, par le biais de liens physiques, à des fichiers partagés. Les sauvegardes complètes ou partielles peuvent être exécutées avec cette méthode, toujours avec la condition que les fichiers avec un contenu identique n'apparaissent qu'une fois dans la sauvegarde.

ArticleIllustration:[One image that will end up at the top of the article]

ArticleBody:[The main part of the article]

Pourquoi un nouvel outil de sauvegarde ?

Il existe déjà des centaines de programmes de sauvegarde. Pourquoi un de plus ? L'origine provient des mes activités en tant que consultant. Je me déplace toute la semaine et je n'ai pas moyen de mettre mes données en sécurité à la maison. Tout ce que j'avais était un lecteur ZIP 250Mo sur mon port parallèle. La sauvegarde sur le ZIP ne me donnait pas beaucoup d'espace de disponible et j'avais de faibles performances (dans les 200ko/s). J'avais, en plus, besoin d'accéder à mes données d'une manière simple et rapide - je n'aime pas les options habituelles de sauvegardes complètes, différentielles et incrémentales (i.e. avec tar ou dump) : d'un coté, il est trop difficile de retrouver une des versions, d'un autre, il n'est pas possible d'effacer de vieilles versions à volonté, cela doit être planifié avec précaution lors de la génération de la sauvegarde.

Mon objectif était de pouvoir sauvegarder mon travail rapidement, trouver mes fichiers tout aussi rapidement et sans soucis.

Donc, fin 1999, la première version de storeBackup a été créée mais n'était pas adapté aux grands environnements. Elle n'était pas suffisament performante, ne compressait pas suffisament et ne pouvait pas dialoguer avec les noms de fichiers spéciaux (i.e. avec un '\n' dans le fichier).

En me basant sur mon expérience avec la première version, j'en ai réécrite une qui a été publiée un peu moins d'un an plus tard sous GPL. Pendant ce temps, le nombre d'utilisateurs a augmenté - depuis une utilisation personnelle, à la mise en sécurité des répertoires (de courriels) chez les fournisseurs ou dans les hopitaux de même que dans les universités et pour l'archivage général.

Comment serait un outil de sauvegarde idéal ?

L'outil de sauvegarde idéal créerait une copie complète de tout le système de données chaque jour (incluant les droits d'accès appliqués) sur un autre système de données avec un minimum d'efforts pour l'administrateur et un maximum de confort pour l'utilisateur. L'ordinateur et les systèmes à disques durs doivent être distants et en sécurité pour que cela soit possible. Avec l'aide d'un navigateur de données, l'utilisateur peut accéder aux données mises en sécurité pour la recherche et la recopie directe de données. La sauvegarde doit être utilisable directement et sans problèmes. Travailler avec les sauvegardes doit devenir « normal » - car la partie administrative sera, en général, inutile.

Le processus décrit ici a un petit désavantage : il a besoin de beaucoup d'espace de disque dur et il est assez lent car à chaque fois, la globalité des donnnées doit être copiée.

Comment fonctionne storeBackup ?

StoreBackup tente d'accomplir la « sauvegarde idéale » et de résoudre les deux problèmes : espace de stockage et performance.

Fonctionalités

La première mesure pour diminuer l'espace disque nécessaire est de compresser les données - si cela est nécessaire. storeBackup permet l'utilisation de tous les algorithmes de compression par l'utilisation de programmes externes. C'est bzip2 par défaut.

En regardant les données de près, il apparaît que de sauvegarde en sauvegarde, relativement peu de fichiers changent - ce qui est la raison des sauvegardes incrémentales. Nous nous sommes aussi rendus compte que beaucoup de fichiers avec les même contenus peuvent être trouvés dans des sauvegardes car les utilisateurs copient des fichiers ou un programme d'administration de versions (comme cvs) est actif. De plus, les fichiers ou les structures de répertoires sont renomés par les utilisateurs, dans les sauvegardes incrémentales, ils sont encore (inutilement) mis en sécurité. La solution est de faire un contrôle de la sauvegarde pour les fichiers ayant le même contenu (pouvant être compressé) et d'y faire une liaison. Le lien physique est cette référence. (Explication : les blocs de données dans les systèmes Unix sont administrés par les inodes. Plusieurs noms de fichiers différents dans autant de répertoires peuvent faire référence à un inode. Le fichier réel est effacé avec son dernier lien physique (=nom de répertoire). (Les liaisons physiques peuvent pointer sur un fichier spécifique dans un seul système de fichiers.)
Avec ce truc sur les liaisons physiques qui sont toujours créées dans des fichiers de sauvegarde existants, chaque fichier est présent dans chaque sauvegarde bien qu'il n'existe physiquement qu'une fois sur le disque dur. La copie et le renomage de fichiers ou de répertoires ne prend que l'espace de stockage sur l'espace de stockage des liens physiques - quasiment rien.

En outre, si plus d'un ordinateur doit être sécurisé, ils ont une forte proportion de fichiers identiques, avec des répertoires comme /etc ou /usr. Il ne doit bien sûr y avoir qu'une seule copie des fichiers identiques stockés dans le disque de sauvegarde. Monter tous les répertoires depuis le serveur de sauvegarde et sauvegarder tous les ordinateurs en une seule passe sera la solution la plus simple. De cette manière, la duplication des fichiers est détectée et ces derniers sont liés physiquement. Cette procédure a néanmoins le désavantage que toutes les machines devant être sécurisés, doivent être disponible pour le temps de la sauvegarde. Cette procédure peut être inaplicable, par exemple, si les portables doivent être sauvegardés en utilisant storeBackup.
Spécialement avec les portables, nous pouvons trouver un temps de retard à la sauvegarde important car les utilisateurs créent des copies locales. Dans de tels cas, si les serveurs sont sauvegardés indépendement les uns des autres et l'espace de disque dur disponible doit être utilisé optimalement par les liaisons physiques, storeBackup permet de lier physiquement les fichiers dans des sauvegardes indépendantes (cela signifie : indépendant les uns des autres, avec la possibilité de différentes machines).

Pour l'effacement des fichiers, storeBackup offre une palette d'options. C'est un grand avantage pour l'effacement lorsque chaque sauvegarde est complète, ils sont effacés sans distinction. Contrairement aux sauvegardes traditionnelles, il n'y a pas besoin de chercher si une sauvegarde incrémentale dépend d'une précédente sauvegarde.
Les options permettent l'effacement ou la sauvegarde sur des jours de travail spécifiques le premier ou dernier jour de la semaine/mois ou année. Il faut s'assurer qu'un minimum de sauvegardes s'effectuent. C'est spécialement utile si les sauvegardes ne sont pas générées sur une base régulière. Il est possible de garder la dernière sauvegarde d'un portable jusqu'à la dernière des 4 semaines même si la période a été définie sur 3 semaines. Il est, de plus, possible de définir le nombre maximum de sauvegardes. Il existe plus d'options pour résoudre l'existence de conflits entre des règles contradictoires (en utilisant le sens commun).

Performance

La procédure décrite ci-dessus suppose qu'une sauvegarde existante est contrôlée pour les fichiers identiques avant de faire une nouvelle sauvegarde d'un fichier. Ceci s'applique aux fichiers de la précédente sauvegarde de même qu'à ceux nouvellement créés. Il n'y a bien sûr pas beaucoup de sens de comparer directement chaque fichier devant être sauvegardés avec ceux de la précédente. Donc les sommes md5 de la sauvegarde précédente sont comparées avec les sommes md5 des fichiers devant être sauvegardés avec l'utilisation des la table de hachage. Le programme utilise les fichiers dbm pour le faire.
Traiter la somme md5 est rapide mais dans le cas de beaucoup de données mais ce n'est pas encore assez rapide. Pour cette raison, storeBackup contrôle initialement si le fichier a été altéré depuis la dernière sauvegarde (chemin + nom de fichier, ctime, mtime et la taille est la même). Si c'est le cas, la somme md5 de la dernière sauvegarde est adoptée et la liaison physique est initialisée. Si le contrôle initial montre une différence, la somme md5 est traitée et un contrôle est effectué pour vérifier si un autre fichier existe avec la même somme md5. (La comparaison avec un numéro des séries de sauvegarde utilise un processus étendu mais similaire en efficacité). Pour cette approche, seules quelques sommes md5 ont besoin d'être calculées pour une sauvegarde.

Mon serveur (200 MHz, IDE) traite de 20 à 35 fichiers/s, mon ordinateur de bureau (800MHz,IDE) à peu près 150 à 200 fichiers/seconde. Sur les ordinateurs rapides avec des bons disques durs (2.4 GHz, 1.4To avec RAID logiciel), j'ai mesuré 800 fichiers/seconde. Ces résultats comprennent l'écriture sur les disques locaux. L'écriture au travers de NFS est beaucoup plus long. La vitesse des disques durs est crutiale. (Tous les tests ont été fait sous Linux).

Implémentations

L'outil storeBackup a été testé sur Linux, FreeBSD, Solaris et AIX. Il devrait fonctionner sur toutes les plates-formes Unix. Perl a été utilisé comme langage de programation.

Installation

L'installation est simple. StoreBackup peut être téléchargé depuis http://www.sf.net/projects/storebackup comme storeBackup version.tar.bz2 et décompressé dans le répertoire souhaité.

tar jxf storeBackup-version.tar.bz2

Ceci crée le répertoire storeBackup avec la documentation et les exécutables dans le sous-répertoire bin. Ils peuvent être appelés avec le chemin complet. Une alternative se fait avec la variable d'environnement $PATH qui doit être initialisée. Les systèmes d'exploitation qui n'ont pas de programme md5sum (i.e. FreeBSD) ont besoin de le compiler. Les instructions pour le faire peuvent ête trouvées dans le fichier README attaché.

Opération

Nous ne pouvons pas décrire ici toutes les options en détail, qui peuvent être trouvées dans le paquet logiciel.

La méthode la plus simple pour générer une sauvegarde est :

storeBackup.pl -s sourceDir -t targetDir

sourceDir et targetDir doivent être existants. StoreBackup copiera les fichiers depuis sourceDir vers targetDir/date_time et dans cette procédure , la compression se fera avec bzip2 (évitant les .gz, bz2, .png, etc.) de même qu'une liaison des fichiers dupliqués.

Dans la version à jour (1.14.1), storeBackup.pl possède 45 paramètres à sa disposition mais leur description est en dehors du champ de cet article. Ils peuvent être accédés avec

storeBackup.pl -h

Dans les fichiers README et EXAMPLES, nous pouvons trouver des explications exhautives sur les différentes applications. Il est à noter que l'alternative de positionner les paramètres dans la ligne de commande - ce qui devient rapidement très complexe - se fait par le biais d'un fichier de configuration. Il peut être généré avec

storeBackup.pl --generate --file ConfigFile

ou plus court avec

storeBackup.pl -g -f ConfigFile

Après la finalisation, la configuration peut être lue, la syntaxe contrôlée et partiellement appliquée par

storeBackup.pl -f ConfigFile --print

en conséquence, storeBackup peut être démarré avec

storeBackup.pl -f ConfigFile

La description complète de toutes les options de storeBackup peut être trouvée dans les fichiers README et EXAMPLES qui forment une partie du fichier tar.

Pour détecter quelle version de fichier existe dans une sauvegarde, storeBackup peut être utilisé :

storeBackupVersion.pl -f Filename

filename est le nom du fichier en question, il doit être écrit de la même manière que dans la sauvegarde, i.e. avec ses attributs de compression. Aller dans le répertoire de sauvegarde au bon endroit et exécuter la commande est la manière la plus facile. Utiliser l'option « -h » montrera les explications des 11 paramètres.

La récupération de fichiers seuls peut être effectuée avec cp, ftp, un navigateur de fichiers ou un système similaire. Pour la récupération partielle de répertoires ou des sauvegardes complètes, il est sensé d'utiliser l'outil storeBackupRecover.pl. Ce dernier extraira les fichiers ou les répertoire de la sauvegarde. Ceci restaurera l'original, i.e. utilisateur, groupe et droits. Les fichiers seront aussi décompressés si c'est le cas dans la version originale. Les liaisons physiques seront aussi rétablies. .
Les options additionelles de storeBackup permettent les lectures statistiques, comme la manipulation des paramètres de performance, les comportements d'écriture et autres. Un total de 10 paramètres peut être vu avec l'option « -h ».

Avec storeBackupDel.pl, les sauvegardes peuvent être effacées indépendement avec le programme storeBackupRecover.pl. Cela peut être utile dans le cas de sauvegarde par NFS. Effacer des répertoires par NFS est beaucoup plus lent que l'effacement local. storeBackup peut être appelé par le NFS sans la fonction d'effacement, permettant un meilleur contrôle de la durée de la sauvegarde. L'effacement de sauvegardes précédement générées se fait avec storeBackupDel - qui, soit dit en passant, possède les mêmes options pour l'effacement que storeBackup - peut être séparé du processus de sauvegarde réel.

Les sauvegardes existantes sont organisées dans des répertoires. Elles sont affichées dans storeBackupls.pl (plus cohérent qu'avec 'ls'). Simplement comme une liste

hjc@schlappix:~/backup ) storeBackupls.pl /media/zip/stbu/
  1  Fri May 23 2003   2003.05.23_12.37.53   -156
  2  Fri Jun 06 2003   2003.06.06_14.31.47   -142
  3  Fri Jun 13 2003   2003.06.13_14.17.18   -135
  4  Fri Jun 20 2003   2003.06.20_14.02.35   -128
  5  Fri Jun 27 2003   2003.06.27_14.23.55   -121
  6  Mon Jun 30 2003   2003.06.30_17.34.37   -118
  7  Fri Jul 04 2003   2003.07.04_13.10.06   -114
  8  Fri Jul 11 2003   2003.07.11_13.13.14   -107
  9  Fri Jul 18 2003   2003.07.18_14.03.49   -100
 10  Fri Jul 25 2003   2003.07.25_14.19.19   -93
 11  Thu Jul 31 2003   2003.07.31_17.07.55   -87
 12  Fri Aug 01 2003   2003.08.01_12.16.58   -86
 13  Fri Aug 15 2003   2003.08.15_15.10.19   -72
 14  Sat Aug 23 2003   2003.08.23_06.25.35   -64
 15  Wed Aug 27 2003   2003.08.27_18.21.09   -60
 16  Thu Aug 28 2003   2003.08.28_14.16.39   -59
 17  Fri Aug 29 2003   2003.08.29_14.35.10   -58
 18  Mon Sep 01 2003   2003.09.01_17.19.56   -55
 19  Tue Sep 02 2003   2003.09.02_18.18.46   -54
 20  Wed Sep 03 2003   2003.09.03_16.22.41   -53
 21  Thu Sep 04 2003   2003.09.04_16.59.19   -52
 22  Fri Sep 05 2003   2003.09.05_14.35.20   -51
 23  Mon Sep 08 2003   2003.09.08_20.08.52   -48
 24  Tue Sep 09 2003   2003.09.09_18.45.48   -47
 25  Wed Sep 10 2003   2003.09.10_18.30.48   -46
 26  Thu Sep 11 2003   2003.09.11_17.26.46   -45
 27  Fri Sep 12 2003   2003.09.12_15.23.03   -44
 28  Mon Sep 15 2003   2003.09.15_18.05.19   -41
 29  Tue Sep 16 2003   2003.09.16_18.04.16   -40
 30  Wed Sep 17 2003   2003.09.17_19.03.02   -39
 31  Thu Sep 18 2003   2003.09.18_18.21.09   -38
 32  Fri Sep 19 2003   2003.09.19_14.48.05   -37  not finished
 33  Mon Sep 22 2003   2003.09.22_18.58.55   -34
 34  Tue Sep 23 2003   2003.09.23_18.48.40   -33
 35  Wed Sep 24 2003   2003.09.24_19.32.24   -32
 36  Thu Sep 25 2003   2003.09.25_18.05.38   -31
 37  Fri Sep 26 2003   2003.09.26_14.59.59   -30
 38  Mon Sep 29 2003   2003.09.29_18.42.59   -27
 39  Tue Sep 30 2003   2003.09.30_18.02.03   -26
 40  Wed Oct 01 2003   2003.10.01_17.09.43   -25
 41  Thu Oct 02 2003   2003.10.02_15.26.33   -24
 42  Mon Oct 06 2003   2003.10.06_20.08.45   -20
 43  Tue Oct 07 2003   2003.10.07_19.46.54   -19
 44  Wed Oct 08 2003   2003.10.08_16.03.23   -18
 45  Thu Oct 09 2003   2003.10.09_16.58.28   -17
 46  Fri Oct 10 2003   2003.10.10_14.21.06   -16
 47  Mon Oct 13 2003   2003.10.13_18.58.24   -13
 48  Tue Oct 14 2003   2003.10.14_16.02.44   -12
 49  Wed Oct 15 2003   2003.10.15_19.04.12   -11
 50  Thu Oct 16 2003   2003.10.16_15.47.51   -10
 51  Mon Oct 20 2003   2003.10.20_09.34.52   -6
 52  Mon Oct 20 2003   2003.10.20_12.16.40   -6
 53  Tue Oct 21 2003   2003.10.21_09.43.40   -5
 54  Tue Oct 21 2003   2003.10.21_11.22.36   -5
 55  Tue Oct 21 2003   2003.10.21_16.01.15   -5
 56  Tue Oct 21 2003   2003.10.21_18.08.07   -5
 57  Wed Oct 22 2003   2003.10.22_10.02.51   -4
 58  Wed Oct 22 2003   2003.10.22_16.09.42   -4
 59  Wed Oct 22 2003   2003.10.22_18.03.05   -4
 60  Thu Oct 23 2003   2003.10.23_08.18.15   -3
 61  Thu Oct 23 2003   2003.10.23_14.16.24   -3
 62  Thu Oct 23 2003   2003.10.23_17.00.36   -3
 63  Fri Oct 24 2003   2003.10.24_13.29.30   -2
 64  Sun Oct 26 2003   2003.10.26_09.08.55   0

'not finished' signifie que la sauvegarde a été annulée).
ou avec des informations sur les conditions d'effacement dans le fichier de configuration :

hjc@schlappix:~/backup ) storeBackupls.pl -f stbu.conf /media/zip/stbu/
analyse of old Backups in </media/zip/stbu/>:
 Fri 2003.05.23_12.37.53 (156): keepLastOfMonth(400d)
 Fri 2003.06.06_14.31.47 (142): keepLastOfWeek(150d)
 Fri 2003.06.13_14.17.18 (135): keepLastOfWeek(150d)
 Fri 2003.06.20_14.02.35 (128): keepLastOfWeek(150d)
 Fri 2003.06.27_14.23.55 (121): keepLastOfWeek(150d)
 Mon 2003.06.30_17.34.37 (118): keepLastOfMonth(400d)
 Fri 2003.07.04_13.10.06 (114): keepLastOfWeek(150d), keepMinNumber50
 Fri 2003.07.11_13.13.14 (107): keepLastOfWeek(150d), keepMinNumber49
 Fri 2003.07.18_14.03.49 (100): keepLastOfWeek(150d), keepMinNumber48
 Fri 2003.07.25_14.19.19 (93): keepLastOfWeek(150d), keepMinNumber47
 Thu 2003.07.31_17.07.55 (87): keepLastOfMonth(400d), keepMinNumber46
 Fri 2003.08.01_12.16.58 (86): keepLastOfWeek(150d), keepMinNumber45
 Fri 2003.08.15_15.10.19 (72): keepLastOfWeek(150d), keepMinNumber44
 Sat 2003.08.23_06.25.35 (64): keepLastOfWeek(150d), keepMinNumber43
 Wed 2003.08.27_18.21.09 (60): keepMinNumber42, keepWeekDays(60d)
 Thu 2003.08.28_14.16.39 (59): keepMinNumber41, keepWeekDays(60d)
 Fri 2003.08.29_14.35.10 (58): keepLastOfMonth(400d), keepLastOfWeek(150d),
                               keepMinNumber40, keepWeekDays(60d)
 Mon 2003.09.01_17.19.56 (55): keepMinNumber39, keepWeekDays(60d)
 Tue 2003.09.02_18.18.46 (54): keepMinNumber38, keepWeekDays(60d)
 Wed 2003.09.03_16.22.41 (53): keepMinNumber37, keepWeekDays(60d)
 Thu 2003.09.04_16.59.19 (52): keepMinNumber36, keepWeekDays(60d)
 Fri 2003.09.05_14.35.20 (51): keepLastOfWeek(150d), keepMinNumber35, keepWeekDays(60d)
 Mon 2003.09.08_20.08.52 (48): keepMinNumber34, keepWeekDays(60d)
 Tue 2003.09.09_18.45.48 (47): keepMinNumber33, keepWeekDays(60d)
 Wed 2003.09.10_18.30.48 (46): keepMinNumber32, keepWeekDays(60d)
 Thu 2003.09.11_17.26.46 (45): keepMinNumber31, keepWeekDays(60d)
 Fri 2003.09.12_15.23.03 (44): keepLastOfWeek(150d), keepMinNumber30, keepWeekDays(60d)
 Mon 2003.09.15_18.05.19 (41): keepMinNumber29, keepWeekDays(60d)
 Tue 2003.09.16_18.04.16 (40): keepMinNumber28, keepWeekDays(60d)
 Wed 2003.09.17_19.03.02 (39): keepMinNumber27, keepWeekDays(60d)
 Thu 2003.09.18_18.21.09 (38): keepMinNumber26, keepWeekDays(60d)
 Fri 2003.09.19_14.48.05 (37): keepLastOfWeek(150d), keepMinNumber25, keepWeekDays(60d)
 Mon 2003.09.22_18.58.55 (34): keepMinNumber24, keepWeekDays(60d)
 Tue 2003.09.23_18.48.40 (33): keepMinNumber23, keepWeekDays(60d)
 Wed 2003.09.24_19.32.24 (32): keepMinNumber22, keepWeekDays(60d)
 Thu 2003.09.25_18.05.38 (31): keepMinNumber21, keepWeekDays(60d)
 Fri 2003.09.26_14.59.59 (30): keepLastOfWeek(150d), keepMinNumber20, keepWeekDays(60d)
 Mon 2003.09.29_18.42.59 (27): keepMinNumber19, keepWeekDays(60d)
 Tue 2003.09.30_18.02.03 (26): keepLastOfMonth(400d), keepMinNumber18, keepWeekDays(60d)
 Wed 2003.10.01_17.09.43 (25): keepMinNumber17, keepWeekDays(60d)
 Thu 2003.10.02_15.26.33 (24): keepLastOfWeek(150d), keepMinNumber16, keepWeekDays(60d)
 Mon 2003.10.06_20.08.45 (20): keepMinNumber15, keepWeekDays(60d)
 Tue 2003.10.07_19.46.54 (19): keepMinNumber14, keepWeekDays(60d)
 Wed 2003.10.08_16.03.23 (18): keepMinNumber13, keepWeekDays(60d)
 Thu 2003.10.09_16.58.28 (17): keepMinNumber12, keepWeekDays(60d)
 Fri 2003.10.10_14.21.06 (16): keepLastOfWeek(150d), keepMinNumber11, keepWeekDays(60d)
 Mon 2003.10.13_18.58.24 (13): keepMinNumber10, keepWeekDays(60d)
 Tue 2003.10.14_16.02.44 (12): keepMinNumber9, keepWeekDays(60d)
 Wed 2003.10.15_19.04.12 (11): keepMinNumber8, keepWeekDays(60d)
 Thu 2003.10.16_15.47.51 (10): keepLastOfWeek(150d), keepMinNumber7, keepWeekDays(60d)
 Mon 2003.10.20_09.34.52 (6): keepDuplicate(7d)
 Mon 2003.10.20_12.16.40 (6): keepMinNumber6, keepWeekDays(60d)
 Tue 2003.10.21_09.43.40 (5): keepDuplicate(7d)
 Tue 2003.10.21_11.22.36 (5): keepDuplicate(7d)
 Tue 2003.10.21_16.01.15 (5): keepDuplicate(7d)
 Tue 2003.10.21_18.08.07 (5): keepMinNumber5, keepWeekDays(60d)
 Wed 2003.10.22_10.02.51 (4): keepDuplicate(7d)
 Wed 2003.10.22_16.09.42 (4): keepDuplicate(7d)
 Wed 2003.10.22_18.03.05 (4): keepMinNumber4, keepWeekDays(60d)
 Thu 2003.10.23_08.18.15 (3): keepDuplicate(7d)
 Thu 2003.10.23_14.16.24 (3): keepDuplicate(7d)
 Thu 2003.10.23_17.00.36 (3): keepMinNumber3, keepWeekDays(60d)
 Fri 2003.10.24_13.29.30 (2): keepLastOfWeek(150d), keepMinNumber2, keepWeekDays(60d)
 Sun 2003.10.26_09.08.55 (0): keepLastOfMonth(400d), keepLastOfWeek(150d),
                              keepMinNumber1, keepWeekDays(60d)

En plus du programme de sauvegarde décrit au-dessus, les programmes llt et multtail sont présents. llt donnera l'affichage des temps de création, modification et derniers accès des fichiers. multitail permet la recherche de certains fichiers comme en utilisant 'tail-f" mais multitail offre plus d'options que 'tail-f' et il est plus robuste.

Plans Futurs

Pour les futures versions de storeBackup, les fonctionalités suivantes sont planifiées :

Le pire consommateur de temps pour la sauvegarde (exceptée la première sauvegarde pendant laquelle tout est compressé et copié) est la liaison physique. Générer une liaison physique est rapide mais à cause de leur grand nombre - comparé aux autres opérations et les opérations parallèles pour la compression, spécifiquement - c'est le plus gourmand en temps.
La version suivante de storeBackup offrira la possibilité de sauvegarder la structure de répertoire et des fichiers modifiés dans une première étape. Ceci concluera la sauvegarde depuis la vue des données devant être sécurisé. Dans la seconde étape, la liaison physique manquante sera créée. Ces deux étapes seront complètement déconnectées l'une de l'autre - cela signifie qu'ils peuvent être lancés sur des machines différentes et qu'il est possible de faire plusieurs sauvegardes avant de générer de nouvelles liaisons physiques.
Les mesures initiales indiquent que cette option aura pour résultat un gain de performance - comparé à une sauvegarde complète « normale » - d'un facteur de 5-10 (1/5 à 1/10 de la « normale »), si une écriture locale est effectuée. La sauvegarde par NFS sera beaucoup plus rapide si vous démarrez le processus pour les liaisons physique localement sur la machine déportée.
Le plan pour la version suivante sera l'extension des possibilités de recherche (avec les sauvegardes sous-jacentes). Il doit être possible de chercher dans les sauvegardes avec des règles définies par l'utilisateur (motif), taille de fichier, temps depuis la génération/changement initial, i.d. utilisateur, i.d. de groupe, droits d'accès sur le fichier et un grep (simple). Les règles inclueront 'and', 'or', 'not' et des parenthèses optionelles.
La vue des futurs plans d'extension est pour des options (à la tar) et le support de nouveaux types de données, i.e. les périphériques.

Version et License

Au moment de l'écriture de cet article, la version actuelle de storeBackup est 1.14.1. et peut être trouvée sur http://www.sf.net/projects/storebackup pour le téléchargement.
StoreBackup est couvert par la GPL.