[Time Machine] Y a t'il un moeyn de savoir ce qu'il copie vraiment ?
18 réponses
pas.de.spam
Bonjour à tous,
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement
Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui
prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go
(jusqu'à 35 !)
alors que je n'ai pas tant modifié de données. Je soupçonne un
fonctionnement erratique quant à certains dossiers : il doit les
recopier intégralement au lieu de ne prendre que ce qui a été modifié à
l'intérieur.
Vu qu'il créedes hard links, un simple coup d'oeil dans les répertoires
ne renseigne pas beaucoup ...
Je crains que ce programme ne soit pas le miracle tant attendu, ... ,
comme beaucoup de ce qui est présenté par Steve Jobs et qui semble si
alléchant à la présentation, hélas ...
Je vais voir ce que ça donne au bout d'une quinzaine de jours, lorsque
les sauvegardes quotidiennes seront éliminées chaque semaine ...
Parce que là, il m'a facile bouffé 100 Go par rapport à la première
sauvegarde ... si ça continue à ce rythme, c'est pas un Mac Pro qu'il va
me falloir, mais une baie de Xsan ... manque de pot, ça se fait plus :D
:D
In article <1ig5oi7.197yhsl1pumcf6N%, (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go (jusqu'à 35 !) alors que je n'ai pas tant modifié de données. Je soupçonne un fonctionnement erratique quant à certains dossiers : il doit les recopier intégralement au lieu de ne prendre que ce qui a été modifié à l'intérieur.
Bon, il y a bien un moyen de le faire. Chaque fichier dans les backup est marqué avec deux "tags", indiquant respectivement le plus ancien et le plus récent backup dans lequel le fichier est présent. Ce qui, en passant, explique pourquoi un backup prend beaucoup de temps même quand il n'y a presque rien à copier : même si TM se contente de faire un hard link sur le même répertoire dans le précédent backup, il va modifier le second tag sur tous les fichiers contenus dans le répertoire !
Donc en utilisant Spotlight, on peut faire une recherche dans le dossier "Backups.backupdb" avec une "raw query" du genre :
Copiés aujourd'hui : _kTimeMachineOldestSnapshot >= $time.today
Copiés hier : (_kTimeMachineOldestSnapshot >= $time.yesterday) && (_kTimeMachineOldestSnapshot < $time.today)
Ou tout autre intervalle en suivant la syntaxe décrite ici : <http://developer.apple.com/documentation/Carbon/Conceptual/ SpotlightQuery/Concepts/QueryFormat.html>
Il est possible de sauvegarder la recherche sous forme de dossier intelligent pour éviter de devoir retaper la query à chaque fois.
Patrick -- Patrick Stadelmann
In article <1ig5oi7.197yhsl1pumcf6N%pas.de.spam@chez.moi>,
pas.de.spam@chez.moi (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement
Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui
prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go
(jusqu'à 35 !)
alors que je n'ai pas tant modifié de données. Je soupçonne un
fonctionnement erratique quant à certains dossiers : il doit les
recopier intégralement au lieu de ne prendre que ce qui a été modifié à
l'intérieur.
Bon, il y a bien un moyen de le faire. Chaque fichier dans les backup
est marqué avec deux "tags", indiquant respectivement le plus ancien et
le plus récent backup dans lequel le fichier est présent. Ce qui, en
passant, explique pourquoi un backup prend beaucoup de temps même quand
il n'y a presque rien à copier : même si TM se contente de faire un hard
link sur le même répertoire dans le précédent backup, il va modifier le
second tag sur tous les fichiers contenus dans le répertoire !
Donc en utilisant Spotlight, on peut faire une recherche dans le dossier
"Backups.backupdb" avec une "raw query" du genre :
Copiés aujourd'hui :
_kTimeMachineOldestSnapshot >= $time.today
Copiés hier :
(_kTimeMachineOldestSnapshot >= $time.yesterday)
&& (_kTimeMachineOldestSnapshot < $time.today)
Ou tout autre intervalle en suivant la syntaxe décrite ici :
<http://developer.apple.com/documentation/Carbon/Conceptual/
SpotlightQuery/Concepts/QueryFormat.html>
Il est possible de sauvegarder la recherche sous forme de dossier
intelligent pour éviter de devoir retaper la query à chaque fois.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1ig5oi7.197yhsl1pumcf6N%, (Pierre-Olivier TAUBATY) wrote:
J'aimerais savoir s'il y un moyen simple de voir ce que copie réellement Time Machine dans une sauvegarde donnée. Car de temps en temps, il lui prend la fantaisie de se mettre à faire une sauvegarde de plusieurs Go (jusqu'à 35 !) alors que je n'ai pas tant modifié de données. Je soupçonne un fonctionnement erratique quant à certains dossiers : il doit les recopier intégralement au lieu de ne prendre que ce qui a été modifié à l'intérieur.
Bon, il y a bien un moyen de le faire. Chaque fichier dans les backup est marqué avec deux "tags", indiquant respectivement le plus ancien et le plus récent backup dans lequel le fichier est présent. Ce qui, en passant, explique pourquoi un backup prend beaucoup de temps même quand il n'y a presque rien à copier : même si TM se contente de faire un hard link sur le même répertoire dans le précédent backup, il va modifier le second tag sur tous les fichiers contenus dans le répertoire !
Donc en utilisant Spotlight, on peut faire une recherche dans le dossier "Backups.backupdb" avec une "raw query" du genre :
Copiés aujourd'hui : _kTimeMachineOldestSnapshot >= $time.today
Copiés hier : (_kTimeMachineOldestSnapshot >= $time.yesterday) && (_kTimeMachineOldestSnapshot < $time.today)
Ou tout autre intervalle en suivant la syntaxe décrite ici : <http://developer.apple.com/documentation/Carbon/Conceptual/ SpotlightQuery/Concepts/QueryFormat.html>
Il est possible de sauvegarder la recherche sous forme de dossier intelligent pour éviter de devoir retaper la query à chaque fois.
Patrick -- Patrick Stadelmann
Paul Gaborit
À (at) Tue, 29 Apr 2008 14:28:20 +0200, Eric Levenez écrivait (wrote):
Le 29/04/08 13:29, dans , « Patrick Stadelmann » a écrit :
Le chiffre semble correspondre au nombre d'éléments (y incluse "." et "..") que contient le dossier. Ce chiffre n'a donc pas le même sens pour un dossier que pour un fichier.
Mince ! Encore un coup du HFS+ ! Vivement qu'il disparaisse.
Ben, c'est comme ça sur la plupart des filesystems unix, non ? Ou alors je n'ai pas compris ce dont vous parliez...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 29 Apr 2008 14:28:20 +0200,
Eric Levenez <usenet@levenez.com> écrivait (wrote):
Le 29/04/08 13:29, dans
<Patrick.Stadelmann-1747A6.13290929042008@individual.net>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
Le chiffre semble correspondre au nombre d'éléments (y incluse "."
et "..") que contient le dossier. Ce chiffre n'a donc pas le même
sens pour un dossier que pour un fichier.
Mince ! Encore un coup du HFS+ ! Vivement qu'il disparaisse.
Ben, c'est comme ça sur la plupart des filesystems unix, non ? Ou
alors je n'ai pas compris ce dont vous parliez...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 29 Apr 2008 14:28:20 +0200, Eric Levenez écrivait (wrote):
Le 29/04/08 13:29, dans , « Patrick Stadelmann » a écrit :
Le chiffre semble correspondre au nombre d'éléments (y incluse "." et "..") que contient le dossier. Ce chiffre n'a donc pas le même sens pour un dossier que pour un fichier.
Mince ! Encore un coup du HFS+ ! Vivement qu'il disparaisse.
Ben, c'est comme ça sur la plupart des filesystems unix, non ? Ou alors je n'ai pas compris ce dont vous parliez...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Eric Levenez
Le 29/04/08 17:05, dans , « Paul Gaborit » a écrit :
Ben, c'est comme ça sur la plupart des filesystems unix, non ? Ou alors je n'ai pas compris ce dont vous parliez...
Non. C'est du spécifique HFS+, un système de fichier Unix "normal" marche comme je l'ai indiqué.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 29/04/08 17:05, dans <wt9iqy0g0qd.fsf@marceau.enstimac.fr>, « Paul
Gaborit » <Paul.Gaborit@invalid.invalid> a écrit :
Ben, c'est comme ça sur la plupart des filesystems unix, non ? Ou
alors je n'ai pas compris ce dont vous parliez...
Non. C'est du spécifique HFS+, un système de fichier Unix "normal" marche
comme je l'ai indiqué.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 29/04/08 17:05, dans , « Paul Gaborit » a écrit :
Ben, c'est comme ça sur la plupart des filesystems unix, non ? Ou alors je n'ai pas compris ce dont vous parliez...
Non. C'est du spécifique HFS+, un système de fichier Unix "normal" marche comme je l'ai indiqué.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
patrick.1200RTcazaux
Pierre-Olivier TAUBATY wrote:
Je crains que ce programme ne soit pas le miracle tant attendu, ... , comme beaucoup de ce qui est présenté par Steve Jobs et qui semble si alléchant à la présentation, hélas ...
T'es sûr que tu ne confonds pas avec Sarkozy ? -- Tardigradus
Je crains que ce programme ne soit pas le miracle tant attendu, ... ,
comme beaucoup de ce qui est présenté par Steve Jobs et qui semble si
alléchant à la présentation, hélas ...
T'es sûr que tu ne confonds pas avec Sarkozy ?
--
Tardigradus
Je crains que ce programme ne soit pas le miracle tant attendu, ... , comme beaucoup de ce qui est présenté par Steve Jobs et qui semble si alléchant à la présentation, hélas ...
T'es sûr que tu ne confonds pas avec Sarkozy ? -- Tardigradus
Anonyme
Laurent Pertois wrote:
Mais bon, tu pourras toujours acheter une baie Promise VTRAK qui remplace les Xserve RAID, ça contient un peu plus et c'est surtout plus rapide :-)
Tiens, à propos, tu en as déjà testé ? C'est vraiment plus rapide ?
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Mais bon, tu pourras toujours acheter une baie Promise VTRAK qui remplace les Xserve RAID, ça contient un peu plus et c'est surtout plus rapide :-)
Tiens, à propos, tu en as déjà testé ? C'est vraiment plus rapide ?
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
laurent.pertois
Anonyme wrote:
Laurent Pertois wrote:
Mais bon, tu pourras toujours acheter une baie Promise VTRAK qui remplace les Xserve RAID, ça contient un peu plus et c'est surtout plus rapide :-)
Tiens, à propos, tu en as déjà testé ?
Yep.
C'est vraiment plus rapide ?
Oui, mais surtout c'est plus souple, les 16 disques sont tous vus par les deux contrôleurs qui sont redondants, ce ne sont plus 2x7 disques contrôlés par 2 contrôleurs indépendants.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Mais bon, tu pourras toujours acheter une baie Promise VTRAK qui
remplace les Xserve RAID, ça contient un peu plus et c'est surtout plus
rapide :-)
Tiens, à propos, tu en as déjà testé ?
Yep.
C'est vraiment plus rapide ?
Oui, mais surtout c'est plus souple, les 16 disques sont tous vus par
les deux contrôleurs qui sont redondants, ce ne sont plus 2x7 disques
contrôlés par 2 contrôleurs indépendants.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Mais bon, tu pourras toujours acheter une baie Promise VTRAK qui remplace les Xserve RAID, ça contient un peu plus et c'est surtout plus rapide :-)
Tiens, à propos, tu en as déjà testé ?
Yep.
C'est vraiment plus rapide ?
Oui, mais surtout c'est plus souple, les 16 disques sont tous vus par les deux contrôleurs qui sont redondants, ce ne sont plus 2x7 disques contrôlés par 2 contrôleurs indépendants.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ patrick proniewski
In article <1ih3xmk.i10xto1b74c4yN%, (Laurent Pertois) wrote:
C'est vraiment plus rapide ?
Oui, mais surtout c'est plus souple, les 16 disques sont tous vus par les deux contrôleurs qui sont redondants, ce ne sont plus 2x7 disques contrôlés par 2 contrôleurs indépendants.
et y'a du RAID 6 :)~~ et on peut ajouter un châssis d'extension pour passer à 32 disques :)~~
yummy. patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <1ih3xmk.i10xto1b74c4yN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
C'est vraiment plus rapide ?
Oui, mais surtout c'est plus souple, les 16 disques sont tous vus par
les deux contrôleurs qui sont redondants, ce ne sont plus 2x7 disques
contrôlés par 2 contrôleurs indépendants.
et y'a du RAID 6 :)~~
et on peut ajouter un châssis d'extension pour passer à 32 disques :)~~
yummy.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
In article <1ih3xmk.i10xto1b74c4yN%, (Laurent Pertois) wrote:
C'est vraiment plus rapide ?
Oui, mais surtout c'est plus souple, les 16 disques sont tous vus par les deux contrôleurs qui sont redondants, ce ne sont plus 2x7 disques contrôlés par 2 contrôleurs indépendants.
et y'a du RAID 6 :)~~ et on peut ajouter un châssis d'extension pour passer à 32 disques :)~~
yummy. patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
laurent.pertois
patpro ~ patrick proniewski wrote:
In article <1ih3xmk.i10xto1b74c4yN%, (Laurent Pertois) wrote:
C'est vraiment plus rapide ?
Oui, mais surtout c'est plus souple, les 16 disques sont tous vus par les deux contrôleurs qui sont redondants, ce ne sont plus 2x7 disques contrôlés par 2 contrôleurs indépendants.
et y'a du RAID 6 :)~~
Voui.
et on peut ajouter un châssis d'extension pour passer à 32 disques :)~~
Voui, aussi.
Et on peut aussi configurer les disques de spare en choisissant par quel LUN ils seront utilisés en cas d'échec d'un disque.
Et l'initialisation des LUNs est aussi bien plus rapide, moins de 10 heures pour une matrice de 6 disques de 750 Go en RAID5 là où ça prenait facilement près de 48 heures avec un Xserve RAID.
Et l'interface d'admin n'est plus en java :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
In article <1ih3xmk.i10xto1b74c4yN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
C'est vraiment plus rapide ?
Oui, mais surtout c'est plus souple, les 16 disques sont tous vus par
les deux contrôleurs qui sont redondants, ce ne sont plus 2x7 disques
contrôlés par 2 contrôleurs indépendants.
et y'a du RAID 6 :)~~
Voui.
et on peut ajouter un châssis d'extension pour passer à 32 disques :)~~
Voui, aussi.
Et on peut aussi configurer les disques de spare en choisissant par quel
LUN ils seront utilisés en cas d'échec d'un disque.
Et l'initialisation des LUNs est aussi bien plus rapide, moins de 10
heures pour une matrice de 6 disques de 750 Go en RAID5 là où ça prenait
facilement près de 48 heures avec un Xserve RAID.
Et l'interface d'admin n'est plus en java :-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
In article <1ih3xmk.i10xto1b74c4yN%, (Laurent Pertois) wrote:
C'est vraiment plus rapide ?
Oui, mais surtout c'est plus souple, les 16 disques sont tous vus par les deux contrôleurs qui sont redondants, ce ne sont plus 2x7 disques contrôlés par 2 contrôleurs indépendants.
et y'a du RAID 6 :)~~
Voui.
et on peut ajouter un châssis d'extension pour passer à 32 disques :)~~
Voui, aussi.
Et on peut aussi configurer les disques de spare en choisissant par quel LUN ils seront utilisés en cas d'échec d'un disque.
Et l'initialisation des LUNs est aussi bien plus rapide, moins de 10 heures pour une matrice de 6 disques de 750 Go en RAID5 là où ça prenait facilement près de 48 heures avec un Xserve RAID.
Et l'interface d'admin n'est plus en java :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
