Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Fiabilité de Time Machine

86 réponses
Avatar
Lionel Mychkine
Je viens d'avoir un gros pépin avec Time Machine alors que jusqu'à
présent je n'avais jamais rencontré le moindre problème.

J'ai tenté de régénérer une sauvegarde sur une partition externe. Tout
semblait se passer normalement mais à la fin du processus, lors du
redémarrage, le système a été incapable de démarrer sur la partition qui
venait d'être restaurée. Le disque n'est pas en cause puisque j'ai pu
réinstaller Mountain Lion à partir des serveurs d'Apple et redémarrer.
Il a fallu que j'efface la partition dédiée à TM et j'ai donc perdu tout
l'historique de plus d'un an.

Apparemment, ce que je fais n'est pas orthodoxe car officiellement, TM
ne sait régénérer une sauvegarde que sur le disque de démarrage à partir
duquel elle a été créée.

Je note que si je n'avais pas tenté cette restauration, je n'aurais
jamais su que mes sauvegardes étaient vérolées. En cas de problème sur
mon disque de démarrage, j'aurais constaté mais un peu tard que j'avais
tout perdu... Je faisais donc des sauvegardes régulièrement pour rien
puisque la base était corrompue ! Pourquoi ? Mystère.

Je me pose une question simple : comment vérifier la fiabilité d'une
sauvegarde TM ? S'il faut la restaurer sur le disque de démarrage pour
avoir la réponse alors que celui-ci fonctionne parfaitement, c'est
franchement dangereux car on risque de tout perdre si la sauvegarde est
défectueuse.

--
Lionel Mychkine

10 réponses

Avatar
pehache
Le 16/10/13 08:25, Gerald a écrit :
La Bete des Vosges (Francis Chartier)
wrote:

Je ne prends pas en compte les problèmes matériels d'écriture sur disque
externe dus à une défaillance du disque, ça aurait impacté n'importe quel
logiciel de la même façon.



Comment faire la différence ? Je veux dire : si TM opère une
vérification (c'est bien !) et détecte des problèmes dans le système de
fichiers,



Foutaises. Même Apple sur la page de support concernant ce problème,
n'ose pas aller jusqu'à que si TM met ce message c'est qu'il a fait une
verif et détecté un problème sur le filesystem (qui est lui aussi écrit
par Apple soit-dit en passant), et qu'on a bien de la chance qu'il l'ait vu.

Non, ils passent au contraire totalement sous silence la cause du truc.

Mais Gerald ose tout.

comment savoir qu'il est responsable de ces problèmes et
qu'ils ne sont pas support-dépendants ?




Tout simplement parce que curieusement, les disques concernés continuent
à fonctionner parfaitement par ailleurs.
Avatar
pehache
Le 16/10/13 11:26, Lionel Mychkine a écrit :
In article
,
Patrick Stadelmann wrote:

Je vérifie avec fsck (Utilitaire de disques), je regarde de temps en
temps le contenu avec BackupLoupe, et occasionnellement je fais une
comparaison avec le disque source (diff -rq) et je vérifie également
régulièrement le log SMART de mes différents disques.



Ouh là, c'est un truc de geek ;-)




Mais non, voyons, c'est Mme Michu-compliant !
Avatar
sebastienmarty
pehache wrote:

Apple utilise là la même rhétorique que la SNCF qui supprime des
dessertes "pour améliorer le service rendu à ses clients". On se demande
qui y croit mais visiblement il y en a...

Le fanboyisme nuit gravement à l'objectivité.



+1. La Geraldisation des esprits est en marche...

--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
Avatar
sebastienmarty
pehache wrote:

Par contre depuis 4 mois, le disque du NAS devenant trop juste (je m'en
sers pour d'autres choses), j'ai remis en service TM sur un disque
externe 2.5" connecté directement au Mac, et pour l'instant ça marche.
J'ai l'impression que c'est sur les sauvegardes réseau que TM se vautre.



Jamais utilisé en réseau, par contre en local j'ai des bugs de temps à
autre en 10.5, mais plus aucun en 10.6.

--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
Avatar
Patrick Stadelmann
In article ,
pehache wrote:

Le 16/10/13 08:25, Gerald a écrit :
> La Bete des Vosges (Francis Chartier)
> wrote:
>
>> Je ne prends pas en compte les problèmes matériels d'écriture sur disque
>> externe dus à une défaillance du disque, ça aurait impacté n'importe quel
>> logiciel de la même façon.
>
> Comment faire la différence ? Je veux dire : si TM opère une
> vérification (c'est bien !) et détecte des problèmes dans le système de
> fichiers,

Foutaises. Même Apple sur la page de support concernant ce problème,
n'ose pas aller jusqu'à que si TM met ce message c'est qu'il a fait une
verif et détecté un problème sur le filesystem (qui est lui aussi écrit
par Apple soit-dit en passant), et qu'on a bien de la chance qu'il l'ait vu.



C'est écrit :

"Time Machine a terminé une vérification de vos sauvegardes"

donc il est bien question de vérification. Comme TM n'a pas de base de
données, index, ou autre... on en déduit que c'est le système de
fichiers qui est vérifié. Hypothèse confirmée au bas de la page, où
Apple donne la procédure pour vérifier une sauvegarde sous 10.5 :

"Si Utilitaire de disque affiche le message « Erreur : échec de la
vérification ou de la réparation du système de fichiers »"

Tout simplement parce que curieusement, les disques concernés continuent
à fonctionner parfaitement par ailleurs.



Ca n'a rien d'exceptionnel s'il s'agit d'un bloc défectueux puisque le
disque le ré-alloue automatiquement. Ensuite, tout peux sembler normal,
le statut SMART indique "PASSED" et le disque peut passer les tests de
surface sans encombre. Ca n'est qu'en consultant l'état SMART détaillé
qu'on peut voir qu'il y a eu des erreurs à un moment donné.

Patrick
--
Patrick Stadelmann
Avatar
Patrick Stadelmann
In article ,
pehache wrote:

Le 16/10/13 11:26, Lionel Mychkine a écrit :
> In article
> ,
> Patrick Stadelmann wrote:
>
>> Je vérifie avec fsck (Utilitaire de disques), je regarde de temps en
>> temps le contenu avec BackupLoupe, et occasionnellement je fais une
>> comparaison avec le disque source (diff -rq) et je vérifie également
>> régulièrement le log SMART de mes différents disques.
>
> Ouh là, c'est un truc de geek ;-)
>

Mais non, voyons, c'est Mme Michu-compliant !



J'explique justement comment on peut aller *au-delà* de la fonction de
base, qui elle s'attache à garantir l'intégrité de la sauvegarde la plus
récente, quitte à sacrifier l'historique si nécessaire.

Patrick
--
Patrick Stadelmann
Avatar
Patrick Stadelmann
In article ,
pehache wrote:

A une échelle moindre que la tienne, je confirme : auparavant je faisais
mes sauvegardes TM sur un NAS, et TM me les bouffait complètement tous
les deux mois. J'ai arrêté il y a 18 mois



Un NAS utilisant netatalk par hasard ? Parce que là il y avait un bug
susceptible de faire foirer les vérifications TM, et qui n'était pas
corrigé il y a 18 mois :

http://netatalk.sourceforge.net/2.2/ReleaseNotes2.2.3.html

"Changed behaviour for TimeMachine volumes in case there’s a problem
talking to the CNID daemons. Previously the volume was flagged
read-only and an AFP message was sent to the client. As this might
result in TimeMachine assuming the backup sparse bundle is damaged, we
now just switch the CNID database to an in-memory tdb without the
additional stuff."

Corrigé dans la version 2.2.3 de mai 2012.

Patrick
--
Patrick Stadelmann
Avatar
pehache
Le 16/10/13 23:00, Patrick Stadelmann a écrit :
In article ,
pehache wrote:

A une échelle moindre que la tienne, je confirme : auparavant je faisais
mes sauvegardes TM sur un NAS, et TM me les bouffait complètement tous
les deux mois. J'ai arrêté il y a 18 mois



Un NAS utilisant netatalk par hasard ? Parce que là il y avait un bug
susceptible de faire foirer les vérifications TM, et qui n'était pas
corrigé il y a 18 mois :

http://netatalk.sourceforge.net/2.2/ReleaseNotes2.2.3.html

"Changed behaviour for TimeMachine volumes in case there’s a problem
talking to the CNID daemons. Previously the volume was flagged
read-only and an AFP message was sent to the client. As this might
result in TimeMachine assuming the backup sparse bundle is damaged, we
now just switch the CNID database to an in-memory tdb without the
additional stuff."

Corrigé dans la version 2.2.3 de mai 2012.




Vu que le bug de TM est rencontré également par les utilisateurs de
Time-Capsule, qui n'utilise pas netatalk je pense, l'explication
netatalk n'est probablement pas la bonne.
Avatar
sebastienmarty
pehache wrote:

Le 16/10/13 23:00, Patrick Stadelmann a écrit :
> In article ,
> pehache wrote:
>
>> A une échelle moindre que la tienne, je confirme : auparavant je faisais
>> mes sauvegardes TM sur un NAS, et TM me les bouffait complètement tous
>> les deux mois. J'ai arrêté il y a 18 mois
>
> Un NAS utilisant netatalk par hasard ? Parce que là il y avait un bug
> susceptible de faire foirer les vérifications TM, et qui n'était pas
> corrigé il y a 18 mois :
>
> http://netatalk.sourceforge.net/2.2/ReleaseNotes2.2.3.html
>
> "Changed behaviour for TimeMachine volumes in case there's a problem
> talking to the CNID daemons. Previously the volume was flagged
> read-only and an AFP message was sent to the client. As this might
> result in TimeMachine assuming the backup sparse bundle is damaged, we
> now just switch the CNID database to an in-memory tdb without the
> additional stuff."
>
> Corrigé dans la version 2.2.3 de mai 2012.
>

Vu que le bug de TM est rencontré également par les utilisateurs de
Time-Capsule, qui n'utilise pas netatalk je pense, l'explication
netatalk n'est probablement pas la bonne.



Mais puisqu'on te dit que ça ne PEUT PAS être un bug venant d'Apple !
L'est-y donc têtu, çui-ci ! :-D

--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
Avatar
pehache
Le 16/10/13 22:41, Patrick Stadelmann a écrit :
In article ,
pehache wrote:

Le 16/10/13 08:25, Gerald a écrit :
La Bete des Vosges (Francis Chartier)
wrote:

Je ne prends pas en compte les problèmes matériels d'écriture sur disque
externe dus à une défaillance du disque, ça aurait impacté n'importe quel
logiciel de la même façon.



Comment faire la différence ? Je veux dire : si TM opère une
vérification (c'est bien !) et détecte des problèmes dans le système de
fichiers,



Foutaises. Même Apple sur la page de support concernant ce problème,
n'ose pas aller jusqu'à que si TM met ce message c'est qu'il a fait une
verif et détecté un problème sur le filesystem (qui est lui aussi écrit
par Apple soit-dit en passant), et qu'on a bien de la chance qu'il l'ait vu.



C'est écrit :

"Time Machine a terminé une vérification de vos sauvegardes"

donc il est bien question de vérification. Comme TM n'a pas de base de
données, index, ou autre... on en déduit que c'est le système de
fichiers qui est vérifié. Hypothèse confirmée au bas de la page, où
Apple donne la procédure pour vérifier une sauvegarde sous 10.5 :

"Si Utilitaire de disque affiche le message « Erreur : échec de la
vérification ou de la réparation du système de fichiers »"

Tout simplement parce que curieusement, les disques concernés continuent
à fonctionner parfaitement par ailleurs.



Ca n'a rien d'exceptionnel s'il s'agit d'un bloc défectueux puisque le
disque le ré-alloue automatiquement. Ensuite, tout peux sembler normal,
le statut SMART indique "PASSED" et le disque peut passer les tests de
surface sans encombre. Ca n'est qu'en consultant l'état SMART détaillé
qu'on peut voir qu'il y a eu des erreurs à un moment donné.




Nombre de secteurs réalloués dans l'état SMART : 0

5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail
Always - 0

Voilà...