j'aimerais centraliser toutes les sauvegardes des ordi familiaux sur une
seule machine (au total, 2GO sur les diverses machines actuelles).
1) La première idée est d'avoir un gros volume et d'y faire une
partition par machine avec sauvegarde par CCC ; bof, avec des partitions
fixes, on est certain de se faire avoir quand les besoins évolueront, et
qu'une des partitions débordera alors que l'autre sera aux 3/4 vide Je
sais que maintenant on arrive à les modifier "live", et que ça
fonctionne assez bien, mais je trouve ça compliqué et pas très safe.
2) sur le gros volume, mettre les time machine de tout le monde.
L'avantage, on profitera au max de la place disponible ; OK, le premier
à arriver au bout obligera tous les autres à commencer à se serrer la
ceinture, mais ça ne me semble pas bien grave. Problème : au vu de ce
qui est rapporté ici, j'ai du mal à considérer TM comme une sauvegarde
fiable.
3) utiliser CCC pour faire des sauvegardes incrémentales dans des
repertoires dédiés d'un gros volume. Ainsi, la place est utilisée au
max. Mais est-on certain de pouvoir reconstruire un disque démarrable à
partir d'un repertoire ?
4) une solution hybride : ne faire des partitions dédiées que pour les
systèmes + appli de chaque machine, et des sauvegardes de type (3) pour
les documents de chacun ?
questions accessoires :
- quand TM arrive à saturer un disque, est-il possible de le transférer
sur un autre sans perdre le lien avec la machine originale ?
- que penser de mettre ce serveur central en RAID 1 pour améliorer la
fiabilité ? ou plutot mettre un deuxième volume de meme taille dans un
autre boitier avec une sauvegarde nocturne automatique ?
- pour le serveur, j'envisage de récupérer une vieille machine un peu
lente ; en incrémental, ce n'est pas trop pénalisant. Mais au moment de
l'initialisation de chaque première sauvegarde ou TM, ça va salement
ramer (surtout pour le réseau, c'est du 100BT). Donc au début,
j'envisage de faire démarrer le système sur une machine rapide et un
bout de réseau Gigabit (sachant que j'utiliserai bien ll'OS du système
serveur, donc démarrage sur disque externe).
Lors du passage en routine, comment faire pour que CCC et/ou TM
reconnaissent leurs cibles ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
gilles
Philippe Manet wrote:
1) La première idée est d'avoir un gros volume et d'y faire une partition par machine avec sauvegarde par CCC
Effectivement ça impose des partitions fixes.
Dans ce cas là ça se fait dans ce sens :
- faire un clone (par utilitaire de disque, CCC, Synchronize ou Superduper) de chaque machine vers sa partition de destination en branchant le disque directement dessus (en USB) à chaque fois
- Puis, tu remets le DD partitionné sur le serveur de fichiers et le partage sur le réseau.
- ensuite tu règles une sauvegarde incrémentale de uniquement le dossier utilisateur, par rsync ou Synchronize, par le réseau.
Avantage : les sauvegardes restent immédiatement bootables.
Inconvénient : seul le dossier utilisateur est mis à jour régulièrement
Pour le système et les applis, il faudra les mettre à jour de temps en temps en branchant le HDD en direct à chaque fois.
Meilleure solution : plutôt que d'utiliser des partitions, tu utilises des fichiers image sparsebundle.
Non seulement c'est fiable (plus que les dmg de faible densité), mais en plus ça évite d'avoir à faire des tailles de partition fixes et ça augmente la sécurité (un sparse bundle peut être crypté, ou demander un mot de passe)
Un sparsebundle ou un dmg hébergé par un serveur afp peut être monté à distance via le réseau comme si c'était un volume local... après, tu en fais ce que tu veux (mise à jour par CCC ou Synchronize)
C'est d'ailleurs comme ça que fonctionne Time Machine
2) sur le gros volume, mettre les time machine de tout le monde. L'avantage, on profitera au max de la place disponible ; OK, le premier à arriver au bout obligera tous les autres à commencer à se serrer la ceinture, mais ça ne me semble pas bien grave. Problème : au vu de ce qui est rapporté ici, j'ai du mal à considérer TM comme une sauvegarde fiable.
Faut pas exagérer... ça marche pour des millions de personnes.
Time machine a des problèmes quand : - il y a un problème matériel - ou quand les gens touchent à l'intérieur des sauvegardes time machine...
Time machine n'aime pas que "quelqu'un d'autre" que lui intervienne dans les dmg ou surtout sur le disque d'origine, car il fonctionne en étant notifié des évènements sur le système de fichiers du disque original et du disque de sauvegarde par les "fsevents".
(d'ailleurs c'est sympa de regarder ce qui se passe sur un Mac avec "FSeventer")
Time machine n'aime pas qu'on lui fasse des modifs dans son dos sans que ça passe par les fsevents (par exemple en modifiant le dd de sauvegarde en le montant sur une autre machine).
Il faut donc que le disque de sauvegarde ne soit pas séparé du serveur qui l'héberge ou modifié. Les time capsule n'ont pas ce problème :-)
Un Mac sous OSX Serveur qui héberge un disque de sauvegarde et le partage comme sauvegarde time machine, si on bidouille pas dedans, ça bouge jamais.
Time machine reste un très bon logiciel.
3) utiliser CCC pour faire des sauvegardes incrémentales dans des repertoires dédiés d'un gros volume. Ainsi, la place est utilisée au max. Mais est-on certain de pouvoir reconstruire un disque démarrable à partir d'un repertoire ?
Non.
Il faut, comme je décris précédemment, soit faire d'abord le clone en "local", puis les m-a-j des dossiers utilisateurs par le réseau, soit mettre à jour un "dmg" hébergé sur le serveur et monté en "local" via le réseau sur la machine.
Je ne sais pas si CCC gère les applescripts, mais je suppose que oui donc tu dois pouvoir faire un applescript pour ouvrir un dmg à distance sur le réseau (en tout cas ça se fait hyper facilement avec synchronize pro)
Par contre, comme un dmg il faudra le restaurer avant de pouvoir booter dessus !
4) une solution hybride : ne faire des partitions dédiées que pour les systèmes + appli de chaque machine, et des sauvegardes de type (3) pour les documents de chacun ?
Ben oui, mais ça revient à la solution 1
questions accessoires : - quand TM arrive à saturer un disque, est-il possible de le transférer sur un autre sans perdre le lien avec la machine originale ?
Oui si c'est un sparsebundle. Plus compliqué si c'est un backupdb.db.
Dans tous les cas, ne t'embêtes pas :
sur ta machine qui héberge les sauvegardes, il suffit de créer à la base un volume JBOD avec un seul disque.
Plutôt que de migrer le HDD, il suffira que tu augmentes la capacité du JBOD en rajoutant au fur et à mesure des nouvelles capacités. Le contenu du JBOD n'est pas bougé, et les dmg hébergés dessus ne seront pas touchés.
Et de toutes façons, Time machine se démerde bien de la suppression des anciennes versions quand l'espace libre est court.
- que penser de mettre ce serveur central en RAID 1 pour améliorer la fiabilité ? ou plutot mettre un deuxième volume de meme taille dans un autre boitier avec une sauvegarde nocturne automatique ?
Bof, RAID1 c'est pour la disponibilité, par pour la sauvegarde. C'est du gachis. le JBOD est bien. Si tu abimes un système de fichier sur un RAID1, ça t'aura rien apporté...
- pour le serveur, j'envisage de récupérer une vieille machine un peu lente ; en incrémental, ce n'est pas trop pénalisant. Mais au moment de l'initialisation de chaque première sauvegarde ou TM, ça va salement ramer (surtout pour le réseau, c'est du 100BT). Donc au début, j'envisage de faire démarrer le système sur une machine rapide et un bout de réseau Gigabit (sachant que j'utiliserai bien ll'OS du système serveur, donc démarrage sur disque externe).
Et la machine lente elle peut pas recevoir une interface Gbit ?
Lors du passage en routine, comment faire pour que CCC et/ou TM reconnaissent leurs cibles ?
Soit les softs de sauvegarde font une comparaison de fichier (Rsync ou Synchronize), dans ce cas ça ne les gène absolument pas que la sauvegarde aie été déplacée, puisqu'ils scannent les fichiers à chaque fois.
Soit ils se basent sur leur propre catalogue (les FSevents pour Timemachine, le catalogue pour Retrospect) et là il faut vraiment que le système de fichiers de la sauvegarde n'aie pas été modifié pour que ça repointe dessus sans problème.
-- le guide de la Ram, hébergé sur disquette par un MacPortable de 1989 : http://aurejac.dyndns.org
Philippe Manet <yapu@invivo.edu> wrote:
1) La première idée est d'avoir un gros volume et d'y faire une
partition par machine avec sauvegarde par CCC
Effectivement ça impose des partitions fixes.
Dans ce cas là ça se fait dans ce sens :
- faire un clone (par utilitaire de disque, CCC, Synchronize ou
Superduper) de chaque machine vers sa partition de destination en
branchant le disque directement dessus (en USB) à chaque fois
- Puis, tu remets le DD partitionné sur le serveur de fichiers et le
partage sur le réseau.
- ensuite tu règles une sauvegarde incrémentale de uniquement le dossier
utilisateur, par rsync ou Synchronize, par le réseau.
Avantage : les sauvegardes restent immédiatement bootables.
Inconvénient : seul le dossier utilisateur est mis à jour régulièrement
Pour le système et les applis, il faudra les mettre à jour de temps en
temps en branchant le HDD en direct à chaque fois.
Meilleure solution : plutôt que d'utiliser des partitions, tu utilises
des fichiers image sparsebundle.
Non seulement c'est fiable (plus que les dmg de faible densité), mais en
plus ça évite d'avoir à faire des tailles de partition fixes et ça
augmente la sécurité (un sparse bundle peut être crypté, ou demander un
mot de passe)
Un sparsebundle ou un dmg hébergé par un serveur afp peut être monté à
distance via le réseau comme si c'était un volume local... après, tu en
fais ce que tu veux (mise à jour par CCC ou Synchronize)
C'est d'ailleurs comme ça que fonctionne Time Machine
2) sur le gros volume, mettre les time machine de tout le monde.
L'avantage, on profitera au max de la place disponible ; OK, le premier
à arriver au bout obligera tous les autres à commencer à se serrer la
ceinture, mais ça ne me semble pas bien grave. Problème : au vu de ce
qui est rapporté ici, j'ai du mal à considérer TM comme une sauvegarde
fiable.
Faut pas exagérer... ça marche pour des millions de personnes.
Time machine a des problèmes quand :
- il y a un problème matériel
- ou quand les gens touchent à l'intérieur des sauvegardes time
machine...
Time machine n'aime pas que "quelqu'un d'autre" que lui intervienne dans
les dmg ou surtout sur le disque d'origine, car il fonctionne en étant
notifié des évènements sur le système de fichiers du disque original et
du disque de sauvegarde par les "fsevents".
(d'ailleurs c'est sympa de regarder ce qui se passe sur un Mac avec
"FSeventer")
Time machine n'aime pas qu'on lui fasse des modifs dans son dos sans que
ça passe par les fsevents (par exemple en modifiant le dd de sauvegarde
en le montant sur une autre machine).
Il faut donc que le disque de sauvegarde ne soit pas séparé du serveur
qui l'héberge ou modifié.
Les time capsule n'ont pas ce problème :-)
Un Mac sous OSX Serveur qui héberge un disque de sauvegarde et le
partage comme sauvegarde time machine, si on bidouille pas dedans, ça
bouge jamais.
Time machine reste un très bon logiciel.
3) utiliser CCC pour faire des sauvegardes incrémentales dans des
repertoires dédiés d'un gros volume. Ainsi, la place est utilisée au
max. Mais est-on certain de pouvoir reconstruire un disque démarrable à
partir d'un repertoire ?
Non.
Il faut, comme je décris précédemment, soit faire d'abord le clone en
"local", puis les m-a-j des dossiers utilisateurs par le réseau, soit
mettre à jour un "dmg" hébergé sur le serveur et monté en "local" via le
réseau sur la machine.
Je ne sais pas si CCC gère les applescripts, mais je suppose que oui
donc tu dois pouvoir faire un applescript pour ouvrir un dmg à distance
sur le réseau (en tout cas ça se fait hyper facilement avec synchronize
pro)
Par contre, comme un dmg il faudra le restaurer avant de pouvoir booter
dessus !
4) une solution hybride : ne faire des partitions dédiées que pour les
systèmes + appli de chaque machine, et des sauvegardes de type (3) pour
les documents de chacun ?
Ben oui, mais ça revient à la solution 1
questions accessoires :
- quand TM arrive à saturer un disque, est-il possible de le transférer
sur un autre sans perdre le lien avec la machine originale ?
Oui si c'est un sparsebundle. Plus compliqué si c'est un backupdb.db.
Dans tous les cas, ne t'embêtes pas :
sur ta machine qui héberge les sauvegardes, il suffit de créer à la base
un volume JBOD avec un seul disque.
Plutôt que de migrer le HDD, il suffira que tu augmentes la capacité du
JBOD en rajoutant au fur et à mesure des nouvelles capacités. Le contenu
du JBOD n'est pas bougé, et les dmg hébergés dessus ne seront pas
touchés.
Et de toutes façons, Time machine se démerde bien de la suppression des
anciennes versions quand l'espace libre est court.
- que penser de mettre ce serveur central en RAID 1 pour améliorer la
fiabilité ? ou plutot mettre un deuxième volume de meme taille dans un
autre boitier avec une sauvegarde nocturne automatique ?
Bof, RAID1 c'est pour la disponibilité, par pour la sauvegarde.
C'est du gachis. le JBOD est bien.
Si tu abimes un système de fichier sur un RAID1, ça t'aura rien
apporté...
- pour le serveur, j'envisage de récupérer une vieille machine un peu
lente ; en incrémental, ce n'est pas trop pénalisant. Mais au moment de
l'initialisation de chaque première sauvegarde ou TM, ça va salement
ramer (surtout pour le réseau, c'est du 100BT). Donc au début,
j'envisage de faire démarrer le système sur une machine rapide et un
bout de réseau Gigabit (sachant que j'utiliserai bien ll'OS du système
serveur, donc démarrage sur disque externe).
Et la machine lente elle peut pas recevoir une interface Gbit ?
Lors du passage en routine, comment faire pour que CCC et/ou TM
reconnaissent leurs cibles ?
Soit les softs de sauvegarde font une comparaison de fichier (Rsync ou
Synchronize), dans ce cas ça ne les gène absolument pas que la
sauvegarde aie été déplacée, puisqu'ils scannent les fichiers à chaque
fois.
Soit ils se basent sur leur propre catalogue (les FSevents
pour Timemachine, le catalogue pour Retrospect) et là il faut vraiment
que le système de fichiers de la sauvegarde n'aie pas été modifié pour
que ça repointe dessus sans problème.
--
le guide de la Ram, hébergé sur disquette par un MacPortable de 1989 :
http://aurejac.dyndns.org
1) La première idée est d'avoir un gros volume et d'y faire une partition par machine avec sauvegarde par CCC
Effectivement ça impose des partitions fixes.
Dans ce cas là ça se fait dans ce sens :
- faire un clone (par utilitaire de disque, CCC, Synchronize ou Superduper) de chaque machine vers sa partition de destination en branchant le disque directement dessus (en USB) à chaque fois
- Puis, tu remets le DD partitionné sur le serveur de fichiers et le partage sur le réseau.
- ensuite tu règles une sauvegarde incrémentale de uniquement le dossier utilisateur, par rsync ou Synchronize, par le réseau.
Avantage : les sauvegardes restent immédiatement bootables.
Inconvénient : seul le dossier utilisateur est mis à jour régulièrement
Pour le système et les applis, il faudra les mettre à jour de temps en temps en branchant le HDD en direct à chaque fois.
Meilleure solution : plutôt que d'utiliser des partitions, tu utilises des fichiers image sparsebundle.
Non seulement c'est fiable (plus que les dmg de faible densité), mais en plus ça évite d'avoir à faire des tailles de partition fixes et ça augmente la sécurité (un sparse bundle peut être crypté, ou demander un mot de passe)
Un sparsebundle ou un dmg hébergé par un serveur afp peut être monté à distance via le réseau comme si c'était un volume local... après, tu en fais ce que tu veux (mise à jour par CCC ou Synchronize)
C'est d'ailleurs comme ça que fonctionne Time Machine
2) sur le gros volume, mettre les time machine de tout le monde. L'avantage, on profitera au max de la place disponible ; OK, le premier à arriver au bout obligera tous les autres à commencer à se serrer la ceinture, mais ça ne me semble pas bien grave. Problème : au vu de ce qui est rapporté ici, j'ai du mal à considérer TM comme une sauvegarde fiable.
Faut pas exagérer... ça marche pour des millions de personnes.
Time machine a des problèmes quand : - il y a un problème matériel - ou quand les gens touchent à l'intérieur des sauvegardes time machine...
Time machine n'aime pas que "quelqu'un d'autre" que lui intervienne dans les dmg ou surtout sur le disque d'origine, car il fonctionne en étant notifié des évènements sur le système de fichiers du disque original et du disque de sauvegarde par les "fsevents".
(d'ailleurs c'est sympa de regarder ce qui se passe sur un Mac avec "FSeventer")
Time machine n'aime pas qu'on lui fasse des modifs dans son dos sans que ça passe par les fsevents (par exemple en modifiant le dd de sauvegarde en le montant sur une autre machine).
Il faut donc que le disque de sauvegarde ne soit pas séparé du serveur qui l'héberge ou modifié. Les time capsule n'ont pas ce problème :-)
Un Mac sous OSX Serveur qui héberge un disque de sauvegarde et le partage comme sauvegarde time machine, si on bidouille pas dedans, ça bouge jamais.
Time machine reste un très bon logiciel.
3) utiliser CCC pour faire des sauvegardes incrémentales dans des repertoires dédiés d'un gros volume. Ainsi, la place est utilisée au max. Mais est-on certain de pouvoir reconstruire un disque démarrable à partir d'un repertoire ?
Non.
Il faut, comme je décris précédemment, soit faire d'abord le clone en "local", puis les m-a-j des dossiers utilisateurs par le réseau, soit mettre à jour un "dmg" hébergé sur le serveur et monté en "local" via le réseau sur la machine.
Je ne sais pas si CCC gère les applescripts, mais je suppose que oui donc tu dois pouvoir faire un applescript pour ouvrir un dmg à distance sur le réseau (en tout cas ça se fait hyper facilement avec synchronize pro)
Par contre, comme un dmg il faudra le restaurer avant de pouvoir booter dessus !
4) une solution hybride : ne faire des partitions dédiées que pour les systèmes + appli de chaque machine, et des sauvegardes de type (3) pour les documents de chacun ?
Ben oui, mais ça revient à la solution 1
questions accessoires : - quand TM arrive à saturer un disque, est-il possible de le transférer sur un autre sans perdre le lien avec la machine originale ?
Oui si c'est un sparsebundle. Plus compliqué si c'est un backupdb.db.
Dans tous les cas, ne t'embêtes pas :
sur ta machine qui héberge les sauvegardes, il suffit de créer à la base un volume JBOD avec un seul disque.
Plutôt que de migrer le HDD, il suffira que tu augmentes la capacité du JBOD en rajoutant au fur et à mesure des nouvelles capacités. Le contenu du JBOD n'est pas bougé, et les dmg hébergés dessus ne seront pas touchés.
Et de toutes façons, Time machine se démerde bien de la suppression des anciennes versions quand l'espace libre est court.
- que penser de mettre ce serveur central en RAID 1 pour améliorer la fiabilité ? ou plutot mettre un deuxième volume de meme taille dans un autre boitier avec une sauvegarde nocturne automatique ?
Bof, RAID1 c'est pour la disponibilité, par pour la sauvegarde. C'est du gachis. le JBOD est bien. Si tu abimes un système de fichier sur un RAID1, ça t'aura rien apporté...
- pour le serveur, j'envisage de récupérer une vieille machine un peu lente ; en incrémental, ce n'est pas trop pénalisant. Mais au moment de l'initialisation de chaque première sauvegarde ou TM, ça va salement ramer (surtout pour le réseau, c'est du 100BT). Donc au début, j'envisage de faire démarrer le système sur une machine rapide et un bout de réseau Gigabit (sachant que j'utiliserai bien ll'OS du système serveur, donc démarrage sur disque externe).
Et la machine lente elle peut pas recevoir une interface Gbit ?
Lors du passage en routine, comment faire pour que CCC et/ou TM reconnaissent leurs cibles ?
Soit les softs de sauvegarde font une comparaison de fichier (Rsync ou Synchronize), dans ce cas ça ne les gène absolument pas que la sauvegarde aie été déplacée, puisqu'ils scannent les fichiers à chaque fois.
Soit ils se basent sur leur propre catalogue (les FSevents pour Timemachine, le catalogue pour Retrospect) et là il faut vraiment que le système de fichiers de la sauvegarde n'aie pas été modifié pour que ça repointe dessus sans problème.
-- le guide de la Ram, hébergé sur disquette par un MacPortable de 1989 : http://aurejac.dyndns.org
yapu
Gilles Aurejac wrote:
Time machine n'aime pas qu'on lui fasse des modifs dans son dos sans que ça passe par les fsevents (par exemple en modifiant le dd de sauvegarde en le montant sur une autre machine).
Il faut donc que le disque de sauvegarde ne soit pas séparé du serveur qui l'héberge ou modifié.
dans ton raisonnement, ce que tu appelles serveur, c'est la machine ou le système de demarrage ? Parce que je comptais mettre le système de demarrage et les time machine sur des disques dans un arranagement constant, mais en changeant uniquement la machine. Mais bon, ça ne sera pas OSX serveur.... mais le 10.5 standard !
et d'ailleurs, si ensuite je passe au 10.6, ça va le perturber ce TM ? -- Philippe Manet en fait, c'est manet avant @
Gilles Aurejac <gilles@alussinan.org> wrote:
Time machine n'aime pas qu'on lui fasse des modifs dans son dos sans que
ça passe par les fsevents (par exemple en modifiant le dd de sauvegarde
en le montant sur une autre machine).
Il faut donc que le disque de sauvegarde ne soit pas séparé du serveur
qui l'héberge ou modifié.
dans ton raisonnement, ce que tu appelles serveur, c'est la machine ou
le système de demarrage ?
Parce que je comptais mettre le système de demarrage et les time machine
sur des disques dans un arranagement constant, mais en changeant
uniquement la machine.
Mais bon, ça ne sera pas OSX serveur.... mais le 10.5 standard !
et d'ailleurs, si ensuite je passe au 10.6, ça va le perturber ce TM ?
--
Philippe Manet
en fait, c'est manet avant @
Time machine n'aime pas qu'on lui fasse des modifs dans son dos sans que ça passe par les fsevents (par exemple en modifiant le dd de sauvegarde en le montant sur une autre machine).
Il faut donc que le disque de sauvegarde ne soit pas séparé du serveur qui l'héberge ou modifié.
dans ton raisonnement, ce que tu appelles serveur, c'est la machine ou le système de demarrage ? Parce que je comptais mettre le système de demarrage et les time machine sur des disques dans un arranagement constant, mais en changeant uniquement la machine. Mais bon, ça ne sera pas OSX serveur.... mais le 10.5 standard !
et d'ailleurs, si ensuite je passe au 10.6, ça va le perturber ce TM ? -- Philippe Manet en fait, c'est manet avant @
yapu
Gilles Aurejac wrote:
Soit les softs de sauvegarde font une comparaison de fichier (Rsync ou Synchronize), dans ce cas ça ne les gène absolument pas que la sauvegarde aie été déplacée, puisqu'ils scannent les fichiers à chaque fois.
bon, pour l'instant coté sauvegarde avec CCC, j'essaie comme suit :
créer le sparseimage sur le mini en faire un alias sur la machine à sauvegarder. CCC a l'air d'accepter de sauvegarder sur cet alias
Bon, restaurer une sparseimage, ce n'est peut-etre pas très rapide, mais pas pire que de reinstaaller SL en passant par Lion de base... -- Philippe Manet en fait, c'est manet avant @
Gilles Aurejac <gilles@alussinan.org> wrote:
Soit les softs de sauvegarde font une comparaison de fichier (Rsync ou
Synchronize), dans ce cas ça ne les gène absolument pas que la
sauvegarde aie été déplacée, puisqu'ils scannent les fichiers à chaque
fois.
bon, pour l'instant coté sauvegarde avec CCC, j'essaie comme suit :
créer le sparseimage sur le mini
en faire un alias sur la machine à sauvegarder.
CCC a l'air d'accepter de sauvegarder sur cet alias
Bon, restaurer une sparseimage, ce n'est peut-etre pas très rapide, mais
pas pire que de reinstaaller SL en passant par Lion de base...
--
Philippe Manet
en fait, c'est manet avant @
Soit les softs de sauvegarde font une comparaison de fichier (Rsync ou Synchronize), dans ce cas ça ne les gène absolument pas que la sauvegarde aie été déplacée, puisqu'ils scannent les fichiers à chaque fois.
bon, pour l'instant coté sauvegarde avec CCC, j'essaie comme suit :
créer le sparseimage sur le mini en faire un alias sur la machine à sauvegarder. CCC a l'air d'accepter de sauvegarder sur cet alias
Bon, restaurer une sparseimage, ce n'est peut-etre pas très rapide, mais pas pire que de reinstaaller SL en passant par Lion de base... -- Philippe Manet en fait, c'est manet avant @
yapu
Gilles Aurejac wrote:
Un sparsebundle ou un dmg hébergé par un serveur afp peut être monté à distance via le réseau comme si c'était un volume local... après, tu en fais ce que tu veux (mise à jour par CCC ou Synchronize)
ton exposé devrait etre archivé par tous les blaireaux de mon genre qui fréquentent ce NG !!! remarquable de sens pratique.
en 10 jours, deux de mes utilisateurs ont vu disparaitre leur disque dur. Comme malgré mes conseils ils n'avaient rien sauvegardé sur le disque que je leur avait filé, ça a couiné... Il me faut donc un truc 100% automatique.
Je sens bien que Time Machine va plaire, mais j'aimerais quand meme avoir des objets clonables et bootables au moins pour le système et la bib de l'user. Je vais créer une sparseimage sur le DD externe du mini (vieux G4 en 100BT pour l'instant), et on va voir comment demander à CCC de la monter automatiquement via le réseau. J'ai vu que CCC savait lancer des scipts shells au démarrage et à la fermeture, mais je en sais pas encore écrire ça... SI ça fonctionne, je ferai les suivantes sur une machine rapide, et le mini ne prendra en charge que les mises à jour.
ça pourrait se faire via un script de fermeture, puisque CCC sait éteindre le Mac après avoir fini sa sauvegarde.
La solution pourrait etre du JBOD avec des sparseimages pour le système/appli de chaque utilisateur, et time machine pour les docs.
Le problème : si je fais du JBOD sur un boitier xxx et que le boitier part en vrille, comment pourrais-je récupérer mes billes ? Parce que j'ai vécu une mauvaise expérience avec des disques RAID0 formatés en ext3 sur un boitier Macway qui est mort, et je fais quoi de mes deux disques...
Au fait, OSX sait faire du JBOD, ou il faut utiliser des boitier externes ? -- Philippe Manet en fait, c'est manet avant @
Gilles Aurejac <gilles@alussinan.org> wrote:
Un sparsebundle ou un dmg hébergé par un serveur afp peut être monté à
distance via le réseau comme si c'était un volume local... après, tu en
fais ce que tu veux (mise à jour par CCC ou Synchronize)
ton exposé devrait etre archivé par tous les blaireaux de mon genre qui
fréquentent ce NG !!! remarquable de sens pratique.
en 10 jours, deux de mes utilisateurs ont vu disparaitre leur disque
dur.
Comme malgré mes conseils ils n'avaient rien sauvegardé sur le disque
que je leur avait filé, ça a couiné...
Il me faut donc un truc 100% automatique.
Je sens bien que Time Machine va plaire, mais j'aimerais quand meme
avoir des objets clonables et bootables au moins pour le système et la
bib de l'user.
Je vais créer une sparseimage sur le DD externe du mini (vieux G4 en
100BT pour l'instant), et on va voir comment demander à CCC de la monter
automatiquement via le réseau. J'ai vu que CCC savait lancer des scipts
shells au démarrage et à la fermeture, mais je en sais pas encore écrire
ça...
SI ça fonctionne, je ferai les suivantes sur une machine rapide, et le
mini ne prendra en charge que les mises à jour.
ça pourrait se faire via un script de fermeture, puisque CCC sait
éteindre le Mac après avoir fini sa sauvegarde.
La solution pourrait etre du JBOD avec des sparseimages pour le
système/appli de chaque utilisateur, et time machine pour les docs.
Le problème : si je fais du JBOD sur un boitier xxx et que le boitier
part en vrille, comment pourrais-je récupérer mes billes ?
Parce que j'ai vécu une mauvaise expérience avec des disques RAID0
formatés en ext3 sur un boitier Macway qui est mort, et je fais quoi de
mes deux disques...
Au fait, OSX sait faire du JBOD, ou il faut utiliser des boitier
externes ?
--
Philippe Manet
en fait, c'est manet avant @
Un sparsebundle ou un dmg hébergé par un serveur afp peut être monté à distance via le réseau comme si c'était un volume local... après, tu en fais ce que tu veux (mise à jour par CCC ou Synchronize)
ton exposé devrait etre archivé par tous les blaireaux de mon genre qui fréquentent ce NG !!! remarquable de sens pratique.
en 10 jours, deux de mes utilisateurs ont vu disparaitre leur disque dur. Comme malgré mes conseils ils n'avaient rien sauvegardé sur le disque que je leur avait filé, ça a couiné... Il me faut donc un truc 100% automatique.
Je sens bien que Time Machine va plaire, mais j'aimerais quand meme avoir des objets clonables et bootables au moins pour le système et la bib de l'user. Je vais créer une sparseimage sur le DD externe du mini (vieux G4 en 100BT pour l'instant), et on va voir comment demander à CCC de la monter automatiquement via le réseau. J'ai vu que CCC savait lancer des scipts shells au démarrage et à la fermeture, mais je en sais pas encore écrire ça... SI ça fonctionne, je ferai les suivantes sur une machine rapide, et le mini ne prendra en charge que les mises à jour.
ça pourrait se faire via un script de fermeture, puisque CCC sait éteindre le Mac après avoir fini sa sauvegarde.
La solution pourrait etre du JBOD avec des sparseimages pour le système/appli de chaque utilisateur, et time machine pour les docs.
Le problème : si je fais du JBOD sur un boitier xxx et que le boitier part en vrille, comment pourrais-je récupérer mes billes ? Parce que j'ai vécu une mauvaise expérience avec des disques RAID0 formatés en ext3 sur un boitier Macway qui est mort, et je fais quoi de mes deux disques...
Au fait, OSX sait faire du JBOD, ou il faut utiliser des boitier externes ? -- Philippe Manet en fait, c'est manet avant @
