Script de clonage vdi et de sauvegarde dans un autre disque

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour,

Je cherche a faire un script journalier qui me permètrais de faire un clone d'une VM virtual box et par la suite le copier sur idealement un nas avec comme condition avoir trois jour d'arièré et ecrit par exemple comme ceci:
Code:

1 2 3 nas://backup/sauvegardeVM-31-12-2018/machinevirtuelle.vdi nas://backup/sauvegardeVM-01-01-2019/machinevirtuelle.vdi nas://backup/sauvegardeVM-02-01-2019/machinevirtuelle.vdi
J'ai un début de code qui tourne dans (/etc/cron.daily) mais sachant que cp ce n'est pas le top j'ai pensé a rsync , l'autre point c'est comment intégré le clonage dans le script qui dois arrété la vm proprement, faire le clone et une fois fini executé la copie :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #!/bin/bash #La date du jour sauvdate=$(date +%d-%m-%Y) #repertoire de la sauvegarde repsauv=/home/user/Documents/sauvegardeVM-$sauvdate #creation du dossier /bin/mkdir $repsauv #lancement de la sauvegarde cp -r /home/user/VirtualBox\ VMs/windows10 $repsauv/windows10

30/09/2018, 19h57
Jipété

Citation:

Envoyé par anje84

Bonjour,

Je cherche à faire un script journalier qui me permettrait de faire un clone d'une VM virtual box

Tu devrais réfléchir au fait qu'un fichier .vdi peut peser quelques Go (machine de test) ou quelques centaines de Go ou plus (machine de prod), et si ça se trouve il n'y a, d'un jour sur l'autre, que quelques mégas utilisés.
Faut-il alors vraiment recopier à chaque fois tout le .vdi ?

Ne serait-il pas plus judicieux de monter le .vdi source et le .vdi destination dans des dossiers et faire tourner rsync sur ces dossiers pour ne recopier que ce qui est effectivement changé ?
Et ensuite on démonte.
Ça serait plus performant, àmha.

Il faut juste blinder le script de tests dans tous les sens pour ne pas avoir de soucis.
30/09/2018, 21h11
anje84

Salut,

C'est une installation que j'ai repris depuis deux semaines derrière un tech qui a laissé les droits d'admin au utilisateurs avec les risques que cela comporte.
pour expliqué m'a démarche, il s'agit des pc d'une personne qui fait tourné des logiciel pour son activité professionnelle sous windows et les pc ont attrapés un ransonware (gandcrabV4) une grosse me**:furieux: , cela fait deux fois que ça se passe en l'espace de deux ans...(j'ai même pas eu le temps de faire le tour de ses besoin et d'appliqué un protocole de sauvegarde et de sécurité, que cette galère m'est tombé dessus)

Du coup il se retrouve avec tout ses bébés crypté et pas moyen de décrypter quoi que ce soit, j'ai reussi a joué avec les shadow copie mais je suis pas confiant, car ces salop**rie de virus savent bien ce caché dans des fichier pdf, exe , ect...

Mon idée c'est de le faire tourné sur un hôte linux des vm windows avec des copies de vdi en prévoyance au cas ou le krab frappe a nouveau quelle grosse mer**ce truc put1:arf:. je ne veut pas travaillé directement sur des images montées avec une sauvegarde différentielle car si virus dormant il y a, j'ai au moins la possibilités d'avoir des images isolé entre elle, quand bien même elle peuvent être toutes vérolées...après je ne doute pas que Linux et aussi vulnérable mais au moins je me sent plus serein:pingoin2: en isolant ces système windows, et puis si problème c'est plus facile de restauré le système complet avec ses logiciel et sa config plutôt que des sauvegardes de logiciel ou de répertoire.
30/09/2018, 23h05
Jipété

Citation:

Envoyé par anje84

et puis si problème c'est plus facile de restaurer le système complet avec ses logiciels et sa config plutôt que des sauvegardes de logiciel ou de répertoire.

Oui, mais moi, je ne parlais pas de restaurer, je parlais de sauvegarder au quotidien.

Alors, recopier un fichier de plusieurs centaines de gigas juste parce qu'une dizaine de fichiers de quelques mégas ont besoin d'être sauvegardés, je trouve que c'est prendre une enclume pour écraser une mouche.

Dans mon idée, la première sauvegarde d'une VM est obligatoirement longue puisque le fichier de destination est vide.
Une fois cela fait, les deux fichiers sont identiques.
Et si le lendemain tu modifies juste un fichier ini de quelques dizaines d'octets dans la VM, as-tu vraiment besoin de backuper tout le .vdi source ? Non ! Tu montes le source, tu montes le destination, tu lances rsync qui ne va backuper que le fichier ini modifié et voilà, tu démontes les vdi's et terminé.
Au final, tu auras tout autant un fichier destination strictement identique au fichier source, tout en ayant économisé beaucoup d'activité disque sur le système de sauvegarde, que veux-tu de plus ?

Un dernier mot : si tu dois recopier avec rsync un fichier de 500 Go, il te faudra un espace disque libre sur la machine de sauvegarde de 500 Go car rsync ne va pas effacer le dernier fichier sauvegardé tant que la copie du nouveau fichier n'est pas terminée : faut de la place...
Avec ma combine, pas besoin.

Bon, maintenant, chacun fait comme il le sent.
01/10/2018, 18h29
Christophe

Il n'y a pas d'obligation de monter les vdi pour faire un rsync dessus. rsync ne va pas recopier l'intégralité d'un gros fichier, uniquement les parties modifiés.

Par ailleurs, pour sauvegarder correctement des fichiers de VM, celles-ci doivent au moins être suspendues.
Les systèmes de sauvegardes de VM déclenchent en général un instantané pour figer le disque, le delta des modifs pendant la sauvegarde étant stocké dans l'instantané, et celui-ci devant être supprimé après (en intégrant les modifs dans le fichier principal). Il n'y a pas à ma connaissance de logiciel spécialisé dans les sauvegardes de VM Virtualbox, contrairement à VMWAre ou Hyper-V.

Mais faire tourner des OS en VM juste pour éviter des virus n'est pas une bonne méthode à mon avis. Il te faut un système de sauvegarde avec versionning et surtout non accessible hors période de sauvegarde. Surtout que tu risques de te retrouver avec une VM vérolée sauvegardée et te rendre compte après de la situation.

Je te conseilles plutôt d’utiliser un logiciel de sauvegarde incrémentielle de type Acronis, ou même l'outil de sauvegarde de Windows, le plus important étant que la destination de la sauvegarde ne doit pas être accessible en dehors du temps de sauvegarde.
01/10/2018, 19h44
Jipété

Salut,

Citation:

Envoyé par chrtophe

Il n'y a pas d'obligation de monter les vdi pour faire un rsync dessus. rsync ne va pas recopier l'intégralité d'un gros fichier, uniquement les parties modifiés.

T'es sûr de ton coup, là ?
Ça ne m'était tellement pas venu à l'esprit que je n'ai jamais eu l'idée de faire des tests dans ce sens.

Et c'est quoi, un gros fichier, vu par rsync ? À partir de quelle taille ?
Et s'il doit emprunter cette voie, comment détecte-t-il les parties à recopier ?
En comparant les deux fichiers byte à byte ?
Me demande si c'est bien performant, ça...

Merci de ton retour,
01/10/2018, 19h56
Christophe

pour la synchro de fichiers, rsync calcule des hashs sur des blocs de ceux-ci dans la source et dans la destination. si il y a une différence, les blocs changés sont envoyés vers la destination.

Pour plus de détail sur l'algorithme :
https://fr.wikipedia.org/wiki/Rsync#Algorithme

Autre précision, rsync est conçu pour faire de la synchro entre deux ordinateurs via le réseau avec support de ssh et compression, mais peut fonctionner avec une source et destination locale comme un disque externe.
01/10/2018, 21h41
anje84

Re,

J'aurais aimé bien entendu passé par un hyperviseur du genre proxmox, hyper-v, esxi ou encore xen...mais faute de moyen et de temps..j'ai fait fissa une install nunux avec une VM windows vite fait en y incluant le minimum necessaire pour relancé l'activité pro du Monsieur.

Par rapport au appli dispo pour virtualbox c'est clair que c'est sec..

Donc actuellement j'ai un pc ( et un autre en attente de réparation) sous linux avec une vm (vdi) windows10 , j'ai le choix de bossé avec des clones et/ou des snapshots, le problème des snapshots c'est que , si tu en perds un en route tu flingue tout ce qui vient après.

Mon idée c'est de faire un script journalier qui:

1-Stop la vm
2-fais un backup clone ou des snapshot ou les deux.. sur un disque local
3-relance la vm
4-Fais une copie du backup sur un nas.
5-Efface les backup trop vieux.

Je compte faire le backup sur un nas en raid1 et avec 4TO de stockage en mirroring, et j'ai limité les VM a 200GO

Question subsidiaire si je restaure un jour la VM comment ne pas perdre les activations de windows, office ect...

Je comprends certain script et j'ai un peu de notion de développement, mais je suis loin d'être a l'aise :oops:.
01/10/2018, 23h29
Jipété

Citation:

Envoyé par chrtophe

pour la synchro de fichiers, rsync calcule des hashs sur des blocs de ceux-ci dans la source et dans la destination. si il y a une différence, les blocs changés sont envoyés vers la destination.

Oui, il est donc bien obligé de parcourir l'intégralité des .vdi source et destination, pas sûr qu'on soit gagnant en termes de performances.

À titre d'exemple, je passe à rsync au quotidien une liste de dossiers pesant bien 500 Go (à la louche) et la sauvegarde ne prend qu'une poignée de dizaines de secondes, quand je me contente de travailler sur des images jpeg ou du son.
Mais je n'ai pas encore mis en prod ce que j'ai préconisé plus haut pour les vdi : c'est toujours en étude, mais le quotidien prend le pas sur les choses à étudier...

Citation:

Envoyé par anje84

Question subsidiaire si je restaure un jour la VM comment ne pas perdre les activations de Windows, Office, etc.

Aucun risque de perdre quoi que ce soit, puisque la sauvegarde d'un .vdi résulte en un autre .vdi strictement identique à l'original.
Scénario en cas de problème : tu arrêtes la MV, tu lui supprimes le disque virtuel cassé, tu lui attaches le disque virtuel sauvegardé, tu relances la MV et ça repart à l'identique.
Teste ce scénario, avant d'aller plus loin dans cette voie.
02/10/2018, 07h49
Christophe

Citation:

Question subsidiaire si je restaure un jour la VM comment ne pas perdre les activations de windows, office ect...

Il faut restaurer la VM complète, pas en recréer une en y intégrant le vdi de l'ancienne (fichier .vbox).

Citation:

Oui, il est donc bien obligé de parcourir l'intégralité des .vdi source et destination, pas sûr qu'on soit gagnant en termes de performances.

À titre d'exemple, je passe à rsync au quotidien une liste de dossiers pesant bien 500 Go (à la louche) et la sauvegarde ne prend qu'une poignée de dizaines de secondes, quand je me contente de travailler sur des images jpeg ou du son.
Mais je n'ai pas encore mis en prod ce que j'ai préconisé plus haut pour les vdi : c'est toujours en étude, mais le quotidien prend le pas sur les choses à étudier...

Si quand-même, surtout que le parcours de fichiers se fait en parallèle A noter qu'il y a un risque (faible) de collision au niveau des hashs. Et attention, rsync ne supprime pas par défaut les fichiers supprimés de la source (il le fait avec l'option --delete-after ou --delete-before).

Mais comme déjà précise, pour moi, la solution utilisée n'est pas bonne.

Bonjour,

Me voici de retour avec un code +/- fonctionnel il me manque le check des trois jours d'anteration...que je ne sais pas comment mis prendre :oops:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 #!/bin/bash VBoxManage controlvm "windowsXp" poweroff sleep 10 #La date du jour sauvdate=$(date +%d-%m-%Y) #repertoire de la sauvegarde repsauv=/media/sdx1/uuid du disk/sauvegarde_VMs/windowsXp_Sauvegarde-$sauvdate #creation du dossier /bin/mkdir $repsauv #lancement de la sauvegarde rsync -arv /media/sdx1/uuid du disk/VirtualBoxVms/windowsXp/ $repsauv VBoxManage startvm "windowsXp"
Comment je peut dire a mon script que je veut que trois jours de fichier de sauvegarde?

08/10/2018, 07h15
Christophe

Regardes ceci.

Bonjour,

Voila ou j'en suis:

Pour l'instant je teste en local le nas n'étant pas encore monté.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 #!/bin/bash message='Arrêt de la machine nomDeLaVm' echo -e "\033[44m$message\033[0m" #Arrêt de la VM VBoxManage controlvm "nomDeLaVm" poweroff sleep 5 messageA='Suppression des sauvegardes de plus de trois jours' echo -e "\033[44m$messageA\033[0m" find /media/user/sda1/sauvegarde_Vms/nomDeLaVm/* -mtime +3 -type d -delete #La date du jour sauvdate=$(date +%d-%m-%Y) #repertoire de la sauvegarde repsauv=/media/user/sda1/sauvegarde_Vms/nomDeLaVm-$sauvdate #creation du dossier /bin/mkdir $repsauv message1='Démarrage de la sauvegarde du : ' echo -e "\033[41m$message1$sauvdate\033[0m" #lancement de la sauvegarde rsync -arv /home/user/VirtualBox\ VMs/DossierDeLaVm/ $repsauv message2='Fin de la sauvegarde et démarrage du nomDeLaVm' echo -e "\033[42m$message2\033[0m" #Démarrage de la VM VBoxManage startvm "nomDeLaVm" sleep 10
Maintenant il me reste plus qu'a voir comment me connecter au nas.

Je me demande comment faire pour ne pas avoir le partage réseau activé (smb, cifs...) en permancence afin d'evité que le disque sois trop de temps accessible sur le lan.
Et ce que je doit obligatoirement passé par du ssh sachant que je rajoute une faille si je le laisse activé ...?
Ces questions sont bien entendu du fait qu'il faut un id et un mdp pour la connexion au nas, je n'est jamais pratiqué cela via script et à part l'echange de cléfs je n'est pas vu de manière différente.

Bonjour,

J'ai monté le nas mais je bloque sur le script comme prévu car a travers ssh c'est pas pareil...je souhaite faire un " find * -type d -exec rm -rv {} \;" avant de lancer la sauvegarde

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#!/bin/bash
 
#find * -type d -exec rm -rv {} \;
 
message='Arrêt de la vm' 
echo -e "\033[44m$message\033[0m"
 
 
VBoxManage controlvm "nom de la vm" poweroff
 
sleep 3
 
 
#La date du jour
sauvdate=$(date +%d-%m-%Y)
 
message1='Démarrage de la sauvegarde du : '
echo -e "\033[41m$message1$sauvdate\033[0m"
 
rsync --progress -arve ssh /ma/source user@ip:/la/destination/$sauvdate
 
message2='Fin de la sauvegarde et démarrage de la vm'
echo -e "\033[42m$message2\033[0m" 
 
sleep 5
 
VBoxManage startvm "nom de la vm"

25/10/2018, 21h57
jack-ft

1 pièce(s) jointe(s)

Oui. Intéressant. Mais encore? Pourquoi bloques-tu?
Et, comme dirait N_BaH:
Pièce jointe 422168
25/10/2018, 22h19
anje84

Et bien je bloque sur la partie ou je veux supprimer les fichier plus vieux de trois jours. En local sur le pc sa passe crème mais via
ssh user@ip find...sa ne passe pas..
j'ai aussi essayé de faire appel a un script
ssh user@ip 'bash-s' < ./mon/repertoire/script.sh
et la non plus...
en gros l'ordre d'exécution cest:

1-arret de la vm
2-suppression du dossier de sauvegarde plus de trois jours
3-lancement de la sauvegarde
4-lancement de la vm

Pour ce qui est du rsync il marche niquel, mais bien avant de le lancé je dois faire le nettoyage dans le dossier distant avec quelque chose comme ça :

Code:

find * -mtime +3 -type d -exec rm -rv {} \;

via du rsync ssh ou du ssh...

Mais je ne c'est pas comment concaténer cette commande dans rsync ou bien dans une connexion ssh avant de lancé la sauvegarde.
Ma question c'est comment supprimer dans le dossier de sauvegarde du nas , les dossier datant de plus de 3 jours avec mon script.

Salut,

rsync possède des options pour faire ce qui pourrait te convenir, mais je n'ai jamais testé et je ne connais pas la syntaxe : il va te falloir googler et tester (crée-toi une arbo de test et joue dessus avant de casser tout ton nas...)

Un peu de lecture (man rsync) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
       --delete
              This tells rsync to delete extraneous files from the receiving side (ones that aren’t on the sending side), but only for the directories
              that  are being synchronized.  You must have asked rsync to send the whole directory (e.g. "dir" or "dir/") without using a wildcard for
              the directory’s contents (e.g. "dir/*") since the wildcard is expanded by the shell and rsync thus gets a request to transfer individual
              files,  not  the files’ parent directory.  Files that are excluded from the transfer are also excluded from being deleted unless you use
              the --delete-excluded option or mark the rules as only matching on the sending side (see the include/exclude  modifiers  in  the  FILTER
              RULES section).
 
              Prior  to rsync 2.6.7, this option would have no effect unless --recursive was enabled.  Beginning with 2.6.7, deletions will also occur
              when --dirs (-d) is enabled, but only for directories whose contents are being copied.
 
              This option can be dangerous if used incorrectly!  It is a very good idea to first try a run using the --dry-run option (-n) to see what
              files are going to be deleted.
 
              If the sending side detects any I/O errors, then the deletion of any files at the destination will be automatically disabled. This is to
              prevent temporary filesystem failures (such as NFS errors) on the sending side from causing a massive deletion of files on the  destina‐
              tion.  You can override this with the --ignore-errors option.
 
              The  --delete  option may be combined with one of the --delete-WHEN options without conflict, as well as --delete-excluded.  However, if
              none of the --delete-WHEN options are specified, rsync will choose the --delete-during algorithm when talking to rsync 3.0.0  or  newer,
              and the --delete-before algorithm when talking to an older rsync.  See also --delete-delay and --delete-after.
 
       --delete-before
              Request  that  the  file-deletions  on  the receiving side be done before the transfer starts.  See --delete (which is implied) for more
              details on file-deletion.
 
              Deleting before the transfer is helpful if the filesystem is tight for space and removing extraneous files would help to make the trans‐
              fer  possible.   However, it does introduce a delay before the start of the transfer, and this delay might cause the transfer to timeout
              (if --timeout was specified).  It also forces rsync to use the old, non-incremental recursion algorithm that requires rsync to scan  all
              the files in the transfer into memory at once (see --recursive).
 
       --delete-during, --del
              Request  that  the file-deletions on the receiving side be done incrementally as the transfer happens.  The per-directory delete scan is
              done right before each directory is checked for updates, so it behaves like a more efficient --delete-before, including doing the  dele‐
              tions  prior  to any per-directory filter files being updated.  This option was first added in rsync version 2.6.4.  See --delete (which
              is implied) for more details on file-deletion.
 
       --delete-delay
              Request that the file-deletions on the receiving side be computed during the transfer (like --delete-during), and then removed after the
              transfer  completes.   This is useful when combined with --delay-updates and/or --fuzzy, and is more efficient than using --delete-after
              (but can behave differently, since --delete-after computes the deletions in a separate pass after all updates are done).  If the  number
              of  removed  files overflows an internal buffer, a temporary file will be created on the receiving side to hold the names (it is removed
              while open, so you shouldn’t see it during the transfer).  If the creation of the temporary file fails, rsync will try to fall  back  to
              using --delete-after (which it cannot do if --recursive is doing an incremental scan).  See --delete (which is implied) for more details
              on file-deletion.
 
       --delete-after
              Request that the file-deletions on the receiving side be done after the transfer has completed.  This is useful if you are  sending  new
              per-directory  merge  files  as  a part of the transfer and you want their exclusions to take effect for the delete phase of the current
              transfer.  It also forces rsync to use the old, non-incremental recursion algorithm that requires rsync to scan all  the  files  in  the
              transfer into memory at once (see --recursive).  See --delete (which is implied) for more details on file-deletion.
 
       --delete-excluded
              In  addition  to deleting the files on the receiving side that are not on the sending side, this tells rsync to also delete any files on
              the receiving side that are excluded (see --exclude).  See the FILTER RULES section for a way to make individual exclusions behave  this
              way  on  the  receiver,  and  for  a  way  to protect files from --delete-excluded.  See --delete (which is implied) for more details on
              file-deletion.

26/10/2018, 09h53
Christophe

l'option --delete de rsync ne permet que de supprimer les fichiers plus présents dans la source, pas de sélectionner ceux-ci selon un critère x ou y.

Pour lancer une commande distante avec ssh :

Code:

ssh utilisateur@machine 'commande distante'
28/10/2018, 23h32
jack-ft

Citation:

Envoyé par anje84

Et bien je bloque sur la partie ou je veux supprimer les fichier plus vieux de trois jours. En local sur le pc sa passe crème mais via
ssh user@ip find...sa ne passe pas..

Déjà merci pour ces précisions, c'est un peu plus clair, mais (car il y a un "mais")...
ce serait sympa de nous préciser ce que veut dire par "ça passe" et "ça ne passe pas".
Par exemple, en nous montrant ce que tu as essayé (la commande précise), puis le résultat observé (avec copie d'un éventuel message d'erreur) et enfin le résultat escompté.

Citation:

je dois faire le nettoyage dans le dossier distant avec quelque chose comme ça :

Code:

find * -mtime +3 -type d -exec rm -rv {} \;

via du rsync ssh ou du ssh...

Mais je ne c'est pas comment concaténer cette commande dans rsync ou bien dans une connexion ssh avant de lancé la sauvegarde.
Ma question c'est comment supprimer dans le dossier de sauvegarde du nas , les dossier datant de plus de 3 jours avec mon script.

Comme indiqué par chrtophe, tu peux faire quelque chose comme:

Code:

ssh user@ip 'find * -mtime +3 -type d -exec rm -rv {} \;'

Mais Attention!!!

Je te conseille de commencer par vérifier si c'est bien ce que tu veux, par exemple en ajoutant un "echo" pour voir:

Code:

ssh user@ip 'find * -mtime +3 -type d -exec echo rm -rv {} \;'

En effet, lorsque tu lances une commande shell sur une machine distante, il vaut mieux savoir dans quel répertoire tu te trouves, par exemple:

Code:

ssh user@ip 'pwd'
29/10/2018, 06h25
anje84

salut
j'ai pas répondu car je suis a fond en ce moment. Mais j'ai fait la même commande que toi en ssh et ça marche, maintenant il faut que j'arrive a fermé la connexion et le terminal une fois la commande terminé , pour lancé le script de sauvegarde derrière.

Voir 40 message(s) de cette discussion en une page