Re: Backup Windows 2000

2000-10-10 Par sujet Daniel Cordey


2. on pourrait imaginer sauvegarder les données dans une raw
   partitions.

Dans ce cas, on doit alors considerer la "raw partition" comme une tape. En
effet, si la taille du backup est bien inferieur a celle de la partition, il
est domage de perdre l'espace non utilise. Il faut alors utiliser des
"marqueurs", comme sur les tapes, pour pouvoir sauter les N premieres ecritures
de la partition. "dd" permet de "deposer" des marques mais il faut etre capable
d'utiliser le "device" en mode "no rewind". Je ne sais pas comment creer un
"raw device" en mode "no rewind" mais un petit coup d'oeil dans la doc devrait
suffire.

Daniel Cordey
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.



Re: Backup Windows 2000

2000-10-10 Par sujet Daniel Cordey

On Tue, 10 Oct 2000, you wrote:
2. on pourrait imaginer sauvegarder les données dans une raw
   partitions.

Complement :
--

dd permet de "sauter" des blocks a l'aide de la commande "skip". Il n'est donc
pas necessaire d'utilliser le "raw device" en mode "no rewind" ! Il suffit de
memoriser le nombre de blocks effectivement ecrits precedement pour aller
ecrire un nouveau "backup" just apres. A priori, il devrait etre possible
d'utilliser dd en combinaison avec 'mt'. Ce qui permettrait d'avoir des
marqueurs entre les backups; donc plus de necessite de memoriser exactement le
nombre de blocks deja ecrits.

Daniel Cordey
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.



Re: Backup Windows 2000

2000-10-10 Par sujet Marc SCHAEFER

On Tue, 10 Oct 2000, Daniel Cordey wrote:

 d'utilliser dd en combinaison avec 'mt'. Ce qui permettrait d'avoir des

pas avec un raw device *disque* (c'est ce que j'entendais). Je ne parlais
pas d'un device tape (car sous Linux, il n'existe pas de raw device en
fait).

Résumons:

  Problème: backuper un fs dans un fichier tar, le résultat est plus que
2 GB, Linux ix86 ne supporte pas, que faire ?

 - backuper sur une tape assez grande
 - backuper dans un raw device disque (/dev/sda, ou une partition),
(mais une INUTILISEE, hein, donc sans fs dessus !)
 - splitter avec la méthode montrée précédemment pour faire un
backup énorme sur plusieurs CDs à la suite
 - utiliser Amanda et l'option chunksize -1, cela coupera le
fichier tar en morceau sur le hold disk (sinon Amanda le
mettra directement sur tape)
 - utiliser afbackup
 - utiliser multivol
 - utiliser filed
 - utiliser 2.4testX et espérer

 marqueurs entre les backups; donc plus de necessite de memoriser
 exactement le nombre de blocks deja ecrits. 

Oui, voici un bout d'une tape Amanda, listée avec le script ci-après.
Amanda met toujours un header de 32k avec les nom/date du backup, les
instructions de restore, puis le backup tar/dump/etc.

pc5 schaefer:/tmp sh /tmp/list_tape.sh a
AMANDA: TAPESTART DATE 2926 TAPE DilogEngSet137
FILE 1 (real: 1) AMANDA: FILE 2926 sun1 /usr lev 0 comp N program 
/usr/local/bin/gtar
FILE 2 (real: 2) AMANDA: FILE 2927 debian /boot lev 1 comp N program /bin/tar
FILE 3 (real: 3) AMANDA: FILE 2927 golid /scratch/world lev 1 comp N program 
/bin/tar
FILE 4 (real: 4) AMANDA: FILE 2927 sun1 / lev 1 comp N program /usr/local/bin/gtar
FILE 5 (real: 5) AMANDA: FILE 2927 golid /spare lev 1 comp N program /bin/tar
FILE 6 (real: 6) AMANDA: FILE 2927 golid / lev 1 comp N program /bin/tar
FILE 7 (real: 7) AMANDA: FILE 2927 golid /users lev 1 comp N program /bin/tar

[ etc ]

Le script: 

#! /bin/sh

TAPE=/dev/nst0
COUNT=1
mt -f $TAPE rewind  dd if=$TAPE bs=32k count=1 2/dev/null | (head -1;
cat  /dev/null)  while mt -f $TAPE fsf 1 ; do
  if [ $# = 0 ]; then
 echo -n "FILE $COUNT "
  else
 echo -n "FILE $COUNT (real: `mt -f /dev/nst0 status | awk '/^file number/ {
 print $NF; }'`) "
  fi
  dd if=$TAPE bs=32k count=1 2/dev/null | (head -1; cat  /dev/null)
  COUNT=`expr $COUNT + 1`
done


--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.



Re: Backup Windows 2000

2000-10-10 Par sujet Francois Deppierraz

Marc SCHAEFER [EMAIL PROTECTED] wrote:

 En 2.4 + nouvelle libc + applications modifiées dans certains cas c'est
 bon.

Je suis pas très chaud pour passer un serveur en production en 2.4.x :)

 Ou sur Alpha, SPARC, etc.

Ca j'aimerais bien mais c'est un peu cher comme matos.

 Alternativement, filed permet de faire quelque chose comme

tar --exclude='proc/*' -cvf - / | filed_client --store --server localhost

Exactement ce qu'il me faudrait.

 Malheureusement filed n'est pas encore terminé (la béta n'est pas encore
 sortie), et j'ai trop de boulot pour le terminer en ce moment.

Dommage, tiens-moi au courant.

 Ma seule recommandation: joue avec les excludes, ou ne backupe que par fs,
 il y a des options de tar pour cela.

Le problème c'est que j'ai un fs de 10 Go à moitié plein qui comporte
que des données importantes... et le backuper dans plusieurs fichiers
complique beaucoup la restauration d'un certain fichier.

-- 
Francois Deppierraz [EMAIL PROTECTED]
Nimag Networks Sàrl - www.nimag.net
PGP Key ID: 9D283BC9
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.



Re: Backup Windows 2000

2000-10-10 Par sujet Francois Deppierraz

Marc SCHAEFER [EMAIL PROTECTED] wrote:

1. afbackup est un outil semble-t-il assez appréciable lorsqu'on n'a
   pas de cassettes ou une seule, et il gère d'après ce j'ai compris
   le saucissonnage

J'ai regardé en vitesse ce afbackup, je pense que je vais me repencher
dessus.

2. on pourrait imaginer sauvegarder les données dans une raw
   partitions.

Avec ce système n'y a-t-il plus de problèmes de taille de fichier ? Si
oui, quelle partie du système impose la limite de 2 Go (kernel,
filesystem, libc) ?

-- 
Francois Deppierraz [EMAIL PROTECTED]
Nimag Networks Sàrl - www.nimag.net
PGP Key ID: 9D283BC9
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.



Re: Backup Windows 2000

2000-10-10 Par sujet Marc SCHAEFER

On 10 Oct 2000, Francois Deppierraz wrote:

 Mais n'y a-t-il pas un problème de fiabilité vu qu'on utilise pas de
 filesystem car il me semble que le filesystem gère lui-même les
 badblocks et ce genre de problèmes, non ?

hum, les disques corrects devraient faire un warning, puis remapper le
bloc lors d'une écriture ou d'une lecture, sauf si les données sont
perdues en lecture et alors une erreur devrait être généré, et le bloc
remplacé.

--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.



Re: Backup Windows 2000

2000-10-10 Par sujet Daniel Cordey

On Tue, 10 Oct 2000, you wrote:

  Mais n'y a-t-il pas un problème de fiabilité vu qu'on utilise pas de
  filesystem car il me semble que le filesystem gère lui-même les
  badblocks et ce genre de problèmes, non ?

Sauf erreur, le hardware/firmware du disque gere deja les bads blocks, les
isole en faisant un "remap" vers un autre block. Chaque disque a une table pour
le remapping. Lorsque cette table est pleine, le disque peut-etre considere
comme en tres mauvais etat. Je ne crois pas que le disque s'occupe de
prevenir le driver a chaque probleme. Par contre il se peut que le driver
examine cette table regulierement, notament lors du "mount". Il se peut aussi
que les pratiques diferent d'un fabricant a l'autre.

Donc pas de probleme pour utiliser un disque pour ce genre d'operation.

Daniel Cordey
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.



Re: Backup Windows 2000

2000-10-10 Par sujet Marc SCHAEFER

On Tue, 10 Oct 2000, Daniel Cordey wrote:

 comme en tres mauvais etat. Je ne crois pas que le disque s'occupe de
 prevenir le driver a chaque probleme. Par contre il se peut que le driver

C'est une option des mode pages dans les disques SCSI. (Read/Write
Recovery).

 examine cette table regulierement, notament lors du "mount". Il se peut aussi
 que les pratiques diferent d'un fabricant a l'autre.

En IDE, je n'ai pas la moindre idée.

--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.



Re: Backup Windows 2000

2000-10-09 Par sujet Yann Souchon

Marc SCHAEFER wrote:

 Oui et non. J'ai à fin de test, au boulot, une image de Windows NT 4.0
 SP5, et une de SP6, créée avec dd
 
dd if=/dev/hda bs=32k of=/dev/nst0
 

En fait je voudrais sauver ça dans un fichier. Est-ce que je peux faire
ça:

dd if=/dev/hda1 bs=32k of=/backup/fichier

Ensuite, je voudrais remettre ça sur une autre partition:

dd if=/backup/fichier bs=32k of=/dev/autre_partition

Ca pause un problème si /dev/autre_partition n'est pas de la même taille
que /dev/hda1 (mais /dev/autre_partition est assez grande)


 En théorie un dd ça se compresse bien (un filesystem, au début, est plein
 de blocks vides).

Si j'ai 1 Go de données sur une partition de 5 Go, le fichier obtenu par
la commande dd fera plutot 1 Go non ?


 Actuellement, la seule façon de backuper un Windows NT complètement depuis
 Linux est soit d'avoir le root filesystem en FAT, soit d'utiliser un
 backup raw (dd).

En parlant de FAT et NTFS, une des différences entre NTFS et FAT c'est
qu'on ne peut pas avoir les droits d'accès sur les fichiers ? En tout
cas chez moi sous Win2k en utilisant une partition en FAT32, il n'y a
pas de droits sur les fichiers.


 (en clair: si vous voulez implémenter quelque chose de compatible
 Microsoft sous Linux, ne signez jamais quoi que ce soit!)

Pour changer :)


A++

 Yann Souchon-   [EMAIL PROTECTED] 
Etudiant EIG Telecom - GPG Key ID: 54B0E099
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.



Re: Backup Windows 2000

2000-10-09 Par sujet Marc SCHAEFER

On Mon, 9 Oct 2000, Yann Souchon wrote:

   dd if=/dev/hda1 bs=32k of=/backup/fichier

Tout a fait valide (tu peux enlever le bs=32k qui ne sert que dans le cas
d'un tape, ou spécifier une valeur plus grosse pour aller plus vite en
théorie). La seule restriction, sous Linux ix86, est que la taille d'un
fichier ne peut dépasser 2 GB. Cela peut être une restriction
inacceptable. Dans ce cas, pourquoi ne pas adapter la solution de backup
permettant de sauver sur plusieurs CDs à la suite (en sauvant sur
fichier.1, .2, .3, etc).

 Ca pause un problème si /dev/autre_partition n'est pas de la même taille
 que /dev/hda1 (mais /dev/autre_partition est assez grande)

oui, et cela peut en poser d'autres si l'OS considéré stocke les
cylindres/têtes/bêtises au lieu des LBAs dans sa structuration.

  En théorie un dd ça se compresse bien (un filesystem, au début, est plein
  de blocks vides).
 
 Si j'ai 1 Go de données sur une partition de 5 Go, le fichier obtenu par
 la commande dd fera plutot 1 Go non ?

non, le fichier fera 5 GByte / GOctets, dd n'interprète pas la
structuration de la partition/du filesystem. Un block non alloué au niveau
du fs existe quand même sur ton disque (rempli de zéro si tu as de la
chance, ou d'anciennes données d'un fichier effacé p.ex.).

Si tu compresses et qu'il n'y a jamais eu plus qu'1 GB, tu auras
vraisemblablement au max 1 GB, voire moins si les données sont
compressibles.

 En parlant de FAT et NTFS, une des différences entre NTFS et FAT c'est
 qu'on ne peut pas avoir les droits d'accès sur les fichiers ? En tout

Pas d'ACLs, pas d'owner, pas de forks. Uh pardon, pas de streams en
langage Microsoft.


--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.