DD via SSH > Sauvegarde/Restauration Partition serveur (VPS)

Demande d'aide : c'est ici.
Répondre
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1042
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

13 févr. 2020, 16:38

Bonjour,

Pour un VPS OVH sous Debian 10


J'ai en mode "Rescue" ⇔ Live Session chargée en RAM :

Code : Tout sélectionner

root@rescue-pro:~# uname -a
Linux rescue-pro 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux

root@rescue-pro:~# cat /etc/debian_version
9.12


Disque du VPS

Code : Tout sélectionner

root@rescue-pro:~# fdisk -l
	Disk /dev/sdb: 20 GiB, 21474836480 bytes, 41943040 sectors
	Units: sectors of 1 * 512 = 512 bytes
	Sector size (logical/physical): 512 bytes / 512 bytes
	I/O size (minimum/optimal): 512 bytes / 512 bytes
	Disklabel type: dos
	Disk identifier: 0x00000000
	
	Device     Boot Start      End  Sectors Size Id Type
	/dev/sdb1  *     2048 41943006 41940959  20G 83 Linux
/dev/sdb est le disque ssd du vps
et /dev/sdb1 son unique partition.



Mon but :


Avant toute autre action :
1. une sauvegarde complète
2. être certain de sa validité
3. être certain de pouvoir la restaurer


Pour l'instant j'ai fait :


Démonter
°°°°°°°°°°°

Code : Tout sélectionner

root@rescue-pro:~# umount /mnt/sdb1

Sauvegarder le MBR
°°°°°°°°°°°°°°°°°°°°

Depuis mon PC

Code : Tout sélectionner

$ ssh root@xx.xx.xx.xx "sudo -S dd if=/dev/sdb " |dd of=vps-mbr-sda.img bs=512 count=1 && md5sum vps-mbr-sda.img > md5

	root@xx.xx.xx.xx's password: 
	sudo: unable to resolve host rescue-pro
	1+0 enregistrements lus
	1+0 enregistrements écrits
	512 octets copiés, 25,1378 s, 0,0 kB/s
dont j'ai comparé le MD5 avec celui obtenu par :

Code : Tout sélectionner

root@rescue-pro:~# dd if=/dev/sdb of=mbr-sda.img bs=512 count=1
=> les MD5 sont égaux.




Sauvegarder la partition
°°°°°°°°°°°°°°°°°°°°°°°°°°°


J'aurais bien utilisé partclone pour profiter d'image plus petites et compressée,
mais je ne suis pas parvenu à exécuter partclone sans devoir enregistrer l'image côté serveur.

J'utilise donc DD

Depuis mon PC

Code : Tout sélectionner

$ ssh root@xx.xx.xx.xx "sudo -S dd if=/dev/sdb1 status=progress | gzip -1 - " | dd of=vps-sda1.img.gz && md5sum vps-sda1.img.gz >> md5
	root@xx.xx.xx.xx's password: 
	sudo: unable to resolve host rescue-pro
	21424570880 bytes (21 GB, 20 GiB) copied, 468 s, 45.8 MB/s     
	41940959+0 records in
	41940959+0 records out
	21473771008 bytes (21 GB, 20 GiB) copied, 468.806 s, 45.8 MB/s
	1093289+121 enregistrements lus
	1093349+1 enregistrements écrits
	559794949 octets (560 MB, 534 MiB) copiés, 505,399 s, 1,1 MB/s
 
Cette commande a produit le fichier image compressé :

-rw-r--r-- 1 dezix dezix 559794949 févr. 13 12:56 vps-sda1.img.gz

et

le fichier extrait :

-rw-r--r-- 1 dezix data-shared 21473771008 févr. 13 13:48 vps-sda1.img

correspond en taille avec les : 512 x 41940959 secteurs = 21 473 771 008 octets donnés par FDISK



Quel moyen pour s'assurer de la validité de cette image ?

Mis à part de tester sa restauration !!!



Restauration
°°°°°°°°°°°°°


Justement,
j'ai des doutes sur ma commande,
j'aurais besoin d'une confirmation/correction (SVP)

Code : Tout sélectionner

$ dd if=vps-sda1.img.gz status=progress | ssh root@xx.xx.xx.xx "sudo -S gzip -dc - | dd of=/dev/sdb1 "
Le but étant (si possible) de décompresser l'image sur le serveur sans l'enregistrer (je ne dispose que de 2 Go de RAM et l'OS de secours est chargé dedans).


Merci.

PS: je suis en cours de test (VM) pour la dernière commande, je reviens avec le resultat
Debian testing/stable - XFCE
PascalHambourg
Contributeur
Contributeur
Messages : 427
Enregistré le : 05 août 2016, 20:25
Status : Hors ligne

13 févr. 2020, 21:56

1) Pourquoi utiliser sudo avec le compte root ?
2) Pourquoi faire des images séparées du MBR et de la partition au lieu d'une image du disque entier ?
3) Si le chargeur d'amorçage est GRUB, une partie est contenue dans les secteurs non alloués situés entre le MBR et la partition. Sauvegarder le MBR ne suffit pas.
dezix a écrit :
13 févr. 2020, 16:38
Quel moyen pour s'assurer de la validité de cette image ?
Par comparaison des sommes de contrôle MD5.
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1042
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

15 févr. 2020, 00:30

Une fois de plus merci pour la critique constructive ...
PascalHambourg a écrit :
13 févr. 2020, 21:56
1) Pourquoi utiliser sudo avec le compte root ?
2) Pourquoi faire des images séparées du MBR et de la partition au lieu d'une image du disque entier ?
3) Si le chargeur d'amorçage est GRUB, une partie est contenue dans les secteurs non alloués situés entre le MBR et la partition. Sauvegarder le MBR ne suffit pas.
dezix a écrit :
13 févr. 2020, 16:38
Quel moyen pour s'assurer de la validité de cette image ?
Par comparaison des sommes de contrôle MD5.

Effectivement, sudo en root est un non-sens
que j'ai bêtement pompé sans prendre le recul suffisant.

Une image du disque complet ... j'y pensais
mais j'avais des doutes,
et en 1er essais j'ai aussi suivi bêtement le même exemple.

Je ne pensais plus à GRUB dans l'espace vide entre MBR et partition (maintenant que j'utilise gpt avec une partition ESP)


Les tests que j'ai pu faire :

D'abord,
Je ne suis pas parvenu à faire des tests sur une VM VBox en live session,
car pas de connexion ssh en live session (rescuecd)


Pour ne pas y perdre trop de temps,
j'ai fais directement les tests sur le VPS,
quitte à réinstaller le VPS en cas d'échec.

J'ai donc refait une image complète du SSD système (/dev/sdb 20Go)
avec :

Code : Tout sélectionner

$ ssh root@xx.xx.xx.xx "dd if=/dev/sdb status=progress | gzip - " | dd of=vps-sda-full.img.gz && md5sum vps-sda-full.img.gz >> md5
root@xx.xx.xx.xx's password: 
21470145536 bytes (21 GB, 20 GiB) copied, 443 s, 48.5 MB/s     
41943040+0 records in
41943040+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 443.308 s, 48.4 MB/s
891415+1 enregistrements lus
891415+1 enregistrements écrits
456404481 octets (456 MB, 435 MiB) copiés, 456,54 s, 1000 kB/s

je me suis ensuite connecté par SSH au VPS toujours en mode Rescue/Live
et j'ai rempli le SSD de zéros avec :

Code : Tout sélectionner

root@rescue-pro:~# dd if=/dev/zero of=/dev/sdb bs=40k conv=notrunc
dd: error writing '/dev/sdb': No space left on device
524289+0 records in
524288+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 233.384 s, 92.0 MB/s
pour être certain de mettre le VPS en avarie.


J'ai restauré le système avec :

Code : Tout sélectionner

$ dd if=vps-sda-full.img.gz status=progress | ssh root@xx.xx.xx.xx " gzip -dc - | dd of=/dev/sdb "
root@xx.xx.xx.xx's password: 
456397312 octets (456 MB, 435 MiB) copiés, 7917 s, 57,6 kB/s
891415+1 enregistrements lus
891415+1 enregistrements écrits
456404481 octets (456 MB, 435 MiB) copiés, 7917,04 s, 57,6 kB/s
41943040+0 records in
41943040+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 8487.16 s, 2.5 MB/s

Vérification

Avant de redémarrer normalement,
et afin de m'assurer de la validité de cette méthode,
j'ai refait une image du SSD complet qui vient d'être restauré.

Ce qui m'a permis de comparer les MD5 des images (extraites) avant et après.

=> les sommes md5 sont égales :))

Remarque : les MD5 des images compressées sont différentes !


Redémarrage en mode normal ⇒ OK!
:yahoo:

Pour moi, la méthode est validée.


Note :

Dans le cas présenté, on avait les tailles suivantes :

/dev/sda = 20Go
espace utilisé = 1.1Go
vps-sda-full.img.gz = 435Mo
vps-sda-full.img = 20Go


Le temps de restauration (upload) est nettement supérieur (1h30) à celui pour récupérer l'image de sauvegarde (15'),
car le débit adsl sortant est très inférieur au débit entrant.

Voilà, si vous avez une meilleure solution,
n'hésitez pas à la partager.

:006:
Debian testing/stable - XFCE
PascalHambourg
Contributeur
Contributeur
Messages : 427
Enregistré le : 05 août 2016, 20:25
Status : Hors ligne

15 févr. 2020, 10:05

dezix a écrit :
15 févr. 2020, 00:30
Je ne pensais plus à GRUB dans l'espace vide entre MBR et partition (maintenant que j'utilise gpt avec une partition ESP)
Dans le format GPT la table de partition n'est plus contenue dans le MBR mais dans les secteurs qui suivent, ça ne change donc pas grand-chose : il faut toujours sauvegarder et restaurer ces secteurs, ou du moins le contenu de la table de partition d'une façon ou d'une autre (par exemple avec sfdisk).

A noter que dans le format traditionnel DOS seule la table de partition principale (partitions 1 à 4) est contenue dans le MBR, pas la table de partition étendue (partitions logiques 5 et suivantes) qui est répartie dans des secteurs situés avant chaque partition logique. Sauvegarder le MBR ne suffit donc pas quand il y a une partition étendue.
dezix a écrit :
15 févr. 2020, 00:30
j'ai refait une image du SSD complet qui vient d'être restauré.
Ce qui m'a permis de comparer les MD5 des images (extraites) avant et après.
Tu aurais pu simplement comparer les sommes MD5 du SSD avant la sauvegarde et après la restauration.

Si tu n'as pas activé le "batch discard" (TRIM périodique), pense à faire un TRIM de la partition avec fstrim afin de marquer tous les blocs vides écrits comme inutilisés.
dezix a écrit :
15 févr. 2020, 00:30
Voilà, si vous avez une meilleure solution,
Meilleure, je ne sais pas. Mais différente : puisque la partition racine est peu remplie, la réduire et créer un seconde partition qui servirait à contenir les sauvegardes du système, voire un système de secours. Cela permettrait de transférer les sauvegardes avec sftp ou scp, ce qui est plus pratique qu'en combinant ssh et dd.
Répondre