Wrong Drive Letter when backup about ovirt_simple_backup

[zipurman]

Try changing the following in backup_attach_image.php
Line 21 : $diskletter = 'a';
Change to: $diskletter = 'b';
to start mounting disks after 'b'

Let me know if that works. I could add a setting to start disk mapping at x.

[zipurman]

You will also want to make this change to xen_add_vbd.php(37) and restore)disk_create.php(33) , reg.php(93)

[nevesigor]

I think this might not be the right approach, when I attach 10 VMS to backup each with 5 disks this will be a mess of discs in the guest.
Also if it's done two backups at the same time with a lot of discs, it will get a lot of messy.
It's there a way to identify the disks attached by uuid inside simple backup machine? That way was perfect, we would know exactly which disks we were doing the backup from.
Maybe smart attribute? Disk attribute when attaching?

[zipurman]

It doesnt work that way. simpleBackup will mount the disks for a given VM, image them, then eject them and move to the next VM to be backed up. There is no issue, as I am backing up many VMs with multiple disks per VM every day. Some people also create clones of VMs, so UUIDs will not be unique, the way I have it works. There is never a case where this script will mount 10 VM's disks all at once.

[nevesigor]

So it will not be possible to backup two VM at the same time with this method?

…

On Thu, 6 Dec 2018, 23:31 Zip ***@***.*** wrote: It doesnt work that way. simpleBackup will mount the disks for a given VM, image them, then eject them and move to the next VM to be backed up. There is no issue, as I am backing up many VMs with multiple disks per VM every day. Some people also create clones of VMs, so UUIDs will not be unique, the way I have it works. There is never a case where this script will mount 10 VM's disks all at once. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ArjFO3ZPtHx6HA15aucE2tjQNAuLuseLks5u2ajOgaJpZM4ZHICC> .

[zipurman]

No. The script will create an array of VMs to be backed up. It will then loop through the array, attaching snapshots and disks as it goes. Once it completes one VM, all the disks are released and it moves on to the next one. If we mounted many VMS disks all at once and imaged all at once ... well that would be a mess.

[zipurman]

I have 30+ VMs on a daily schedule. It will back them all up within 90 minutes onto remote NFS. There is no down time as it creates snapshots to do the imaging. It is automated and there is no issue. I then get an email report when it is completed. Is that not what you are looking for?

[nevesigor]

That drive letter bypass, for now it's ok, I'm just trying to understand the limitations.

Anyway when you implement the incremental backups you mention today, that will help a lot.

I will test this code tomorrow and let you know.

[nevesigor]

The code seems to work in some part, but it breaks in some another point, I'm trying to reach you on IRC, very fuzzy to "chat" over here, let's see if I can find you later today to share my experience.

[zipurman]

Have a look at the logs to see where it breaks. I am always on irc.oftc.net:6667 #ovirt