Jump to content
danioj

unraid-autovmbackup: automate backup of virtual machines in unRAID - v0.4

167 posts in this topic Last Reply

Recommended Posts

Great script.

Thoughts on why the script bailed on me, seems like it can't fine the log file.

2018-03-23 15:03 information: number_of_error_log_files_to_keep is 10. this is probably a sufficient error number of log files to keep.
2018-03-23 15:03 information: started attempt to backup srv-ubuntu to /mnt/user/backup/domains
2018-03-23 15:03 information: srv-ubuntu can be found on the system. attempting backup.
2018-03-23 15:03 action: /mnt/user/backup/domains/srv-ubuntu does not exist. creating it.
mkdir: created directory '/mnt/user/backup/domains/srv-ubuntu'
2018-03-23 15:03 information: srv-ubuntu is shut off. can_backup_vm set to y
2018-03-23 15:03 action: can_backup_vm flag is y. starting backup of srv-ubuntu xml configuration and vdisk(s).
2018-03-23 15:03 action: actually_copy_files is 1.
sending incremental file list
srv-ubuntu.xml

sent 5,479 bytes received 35 bytes 11,028.00 bytes/sec
total size is 5,379 speedup is 0.98
2018-03-23 15:03 information: backup of srv-ubuntu xml configuration to /mnt/user/backup/domains/srv-ubuntu/20180323_1503_srv-ubuntu.xml complete.
2018-03-23 15:03 action: actually_copy_files is 1.
'/mnt/user/kvm/domains/srv-ubuntu/vdisk1.img' -> '/mnt/user/backup/domains/srv-ubuntu/20180323_1503_vdisk1.img'
2018-03-23 15:04 information: backup of vdisk1.img vdisk to /mnt/user/backup/domains/srv-ubuntu/20180323_1503_vdisk1.img complete.
2018-03-23 15:04 warning: /mnt/user/kvm/isos/mini.iso of srv-ubuntu is not a vdisk. skipping.
2018-03-23 15:04 information: vm_original_state is shut off. not starting srv-ubuntu.
tar: Removing leading `/' from member names
tar: /mnt/user/backup/domains/srv-ubuntu/*.{xml,img,qcow2}: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
2018-03-23 15:04 information: backup of srv-ubuntu to /mnt/user/backup/domains/srv-ubuntu completed.
2018-03-23 15:04 information: nubmer of days to keep backups set to indefinitely.
2018-03-23 15:04 information: cleaning out backups over 1 in location /mnt/user/backup/domains/srv-ubuntu/
ls: cannot access '/mnt/user/backup/domains/srv-ubuntu/*.qcow2': No such file or directory
2018-03-23 15:04 information: finished attempt to backup srv-ubuntu to /mnt/user/backup/domains.
2018-03-23 15:04 information: cleaning out logs over 1.
2018-03-23 15:04 information: cleaning out error logs over 10.
ls: cannot access '/mnt/user/backup/domains/logs/*unraid-vmbackup_error.log': No such file or directory
2018-03-23 15:04 warning: errors found. creating error log file.
sending incremental file list
20180323_1503_unraid-vmbackup.log

sent 3,951 bytes received 35 bytes 7,972.00 bytes/sec
total size is 3,832 speedup is 0.96
Script Finished Fri, 23 Mar 2018 15:04:08 -0400

Full logs for this script are available at /tmp/user.scripts/tmpScripts/unraid-vmbackup/log.txt

 

# ls -al /mnt/user/backup/domains/logs/
total 8
drwxrwxrwx 1 root root  106 Mar 23 15:04 ./
drwxrwxrwx 1 root root   74 Mar 23 15:03 ../
-rw-rw-rw- 1 root root 3832 Mar 23 15:04 20180323_1503_unraid-vmbackup.log
-rw-rw-rw- 1 root root 3832 Mar 23 15:04 20180323_1503_unraid-vmbackup_error.log
# ls -al /mnt/user/backup/domains/srv-ubuntu
total 3533176
drwxrwxrwx 1 root root         129 Mar 23 15:04 ./
drwxrwxrwx 1 root root          74 Mar 23 15:03 ../
-rw-rw-rw- 1 root root          45 Mar 23 15:04 20180323_1503_srv-ubuntu.tar.gz
-rw-rw-rw- 1 root root        5379 Mar 23 15:03 20180323_1503_srv-ubuntu.xml
-rwxrwxrwx 1 root root 10737418240 Mar 23 15:04 20180323_1503_vdisk1.img*

 

Share this post


Link to post
Great script.
Thoughts on why the script bailed on me, seems like it can't fine the log file.
2018-03-23 15:03 information: number_of_error_log_files_to_keep is 10. this is probably a sufficient error number of log files to keep.2018-03-23 15:03 information: started attempt to backup srv-ubuntu to /mnt/user/backup/domains2018-03-23 15:03 information: srv-ubuntu can be found on the system. attempting backup.2018-03-23 15:03 action: /mnt/user/backup/domains/srv-ubuntu does not exist. creating it.mkdir: created directory '/mnt/user/backup/domains/srv-ubuntu'2018-03-23 15:03 information: srv-ubuntu is shut off. can_backup_vm set to y2018-03-23 15:03 action: can_backup_vm flag is y. starting backup of srv-ubuntu xml configuration and vdisk(s).2018-03-23 15:03 action: actually_copy_files is 1.sending incremental file listsrv-ubuntu.xmlsent 5,479 bytes received 35 bytes 11,028.00 bytes/sectotal size is 5,379 speedup is 0.982018-03-23 15:03 information: backup of srv-ubuntu xml configuration to /mnt/user/backup/domains/srv-ubuntu/20180323_1503_srv-ubuntu.xml complete.2018-03-23 15:03 action: actually_copy_files is 1.'/mnt/user/kvm/domains/srv-ubuntu/vdisk1.img' -> '/mnt/user/backup/domains/srv-ubuntu/20180323_1503_vdisk1.img'2018-03-23 15:04 information: backup of vdisk1.img vdisk to /mnt/user/backup/domains/srv-ubuntu/20180323_1503_vdisk1.img complete.2018-03-23 15:04 warning: /mnt/user/kvm/isos/mini.iso of srv-ubuntu is not a vdisk. skipping.2018-03-23 15:04 information: vm_original_state is shut off. not starting srv-ubuntu.tar: Removing leading `/' from member namestar: /mnt/user/backup/domains/srv-ubuntu/*.{xml,img,qcow2}: Cannot stat: No such file or directorytar: Exiting with failure status due to previous errors2018-03-23 15:04 information: backup of srv-ubuntu to /mnt/user/backup/domains/srv-ubuntu completed.2018-03-23 15:04 information: nubmer of days to keep backups set to indefinitely.2018-03-23 15:04 information: cleaning out backups over 1 in location /mnt/user/backup/domains/srv-ubuntu/ls: cannot access '/mnt/user/backup/domains/srv-ubuntu/*.qcow2': No such file or directory2018-03-23 15:04 information: finished attempt to backup srv-ubuntu to /mnt/user/backup/domains.2018-03-23 15:04 information: cleaning out logs over 1.2018-03-23 15:04 information: cleaning out error logs over 10.ls: cannot access '/mnt/user/backup/domains/logs/*unraid-vmbackup_error.log': No such file or directory2018-03-23 15:04 warning: errors found. creating error log file.sending incremental file list20180323_1503_unraid-vmbackup.logsent 3,951 bytes received 35 bytes 7,972.00 bytes/sectotal size is 3,832 speedup is 0.96Script Finished Fri, 23 Mar 2018 15:04:08 -0400Full logs for this script are available at /tmp/user.scripts/tmpScripts/unraid-vmbackup/log.txt

 

# ls -al /mnt/user/backup/domains/logs/total 8drwxrwxrwx 1 root root  106 Mar 23 15:04 ./drwxrwxrwx 1 root root   74 Mar 23 15:03 ../-rw-rw-rw- 1 root root 3832 Mar 23 15:04 20180323_1503_unraid-vmbackup.log-rw-rw-rw- 1 root root 3832 Mar 23 15:04 20180323_1503_unraid-vmbackup_error.log

# ls -al /mnt/user/backup/domains/srv-ubuntutotal 3533176drwxrwxrwx 1 root root         129 Mar 23 15:04 ./drwxrwxrwx 1 root root          74 Mar 23 15:03 ../-rw-rw-rw- 1 root root          45 Mar 23 15:04 20180323_1503_srv-ubuntu.tar.gz-rw-rw-rw- 1 root root        5379 Mar 23 15:03 20180323_1503_srv-ubuntu.xml-rwxrwxrwx 1 root root 10737418240 Mar 23 15:04 20180323_1503_vdisk1.img*

 



It's because I made a mistake with quotation marks I think. I'm on my phone, so it's a little tough to tell for sure, but I'm pretty sure that's what happening. I will make sure it's fixed in the release for next week.



Sorry about that.



Sent from my iPhone using Tapatalk

Share this post


Link to post
4 hours ago, JTok said:

 

That should be easy enough to add. I'll add it to my to-do list. I'm planning on having the next version out sometime next week, and I think I should be able to get this into that release.

 

Awesome!

Share this post


Link to post

Okay, let's try this again. I've put a new version out. It addresses the concerns of @joelones and @PieQuest as well as a few other fixes and enhancements.

 

  • Added option to only receive error notifications.
  • Added option to receive detailed notifications.
    • Sends notifications when VM backups are started and stopped.
    • Sends notifications when old backups are deleted.
    • Sends notifications when old log files are deleted.
  • Added option to backup nvram. Enabled by default.
  • Fixed issues with notification system.
    • Not all failures and warnings were using notifications.
    • send_notifications variable wasn't disabling many notifications.
  • Fixed issues with tarball backups not removing original files.
  • Fixed issues with log files not being removed.
  • Fixed logging issues.
    • Detailed logging for tarballs.
    • Logging for rm commands.
  • Updated notification message language.
  • Updated script comments/directions.

 

Same deal as the previous updates. I've tested as best I can, but I can't guarantee everything. 

 

The script can still be found here: https://github.com/JTok/unraid-vmbackup

 

-JTok

Edited by JTok

Share this post


Link to post

@JTok

Tried the new version of the script, appears it finished with another error due to a log file, although I believe it did its thing?

 

drwxrwxrwx 1 nobody users  120 Apr 11 11:29 ../
-rw-rw-rw- 1 root   root  4380 Apr 11 11:34 20180411_1129_unraid-vmbackup.log
-rw-rw-rw- 1 root   root  4380 Apr 11 11:34 20180411_1129_unraid-vmbackup_error.log
root@Tower:/mnt/user/backup/domains#

 

I was left with a single zipped tarball within the backup directory.

 

Also, decompressing the backup reveals that it recreates the complete backup path as specified in the script variable, (mnt/user/backup/domains/srv-ubuntu/,... in my case). Not sure that was intended or not? Shouldn't it simply decompress the files without the whole path?

 

total size is 131,072 speedup is 1.00
2018-04-11 11:29 information: backup of srv-ubuntu nvram to /mnt/user/backup/domains/srv-ubuntu/20180411_1129_bab60192-5d43-b8df-1be5-a7a9c7ab6c7f_VARS-pure-efi.fd complete.
'/mnt/user/kvm/domains/srv-ubuntu/vdisk1.img' -> '/mnt/user/backup/domains/srv-ubuntu/20180411_1129_vdisk1.img'
2018-04-11 11:30 information: backup of vdisk1.img vdisk to /mnt/user/backup/domains/srv-ubuntu/20180411_1129_vdisk1.img complete.
2018-04-11 11:30 warning: /mnt/user/kvm/isos/mini.iso of srv-ubuntu is not a vdisk. skipping.
2018-04-11 11:30 information: vm_original_state is shut off. not starting srv-ubuntu.
2018-04-11 11:30 information: started creating new tarball.
tar: Removing leading `/' from member names
/mnt/user/backup/domains/srv-ubuntu/20180411_1129_srv-ubuntu.xml
tar: Removing leading `/' from hard link targets
/mnt/user/backup/domains/srv-ubuntu/20180411_1129_bab60192-5d43-b8df-1be5-a7a9c7ab6c7f_VARS-pure-efi.fd
/mnt/user/backup/domains/srv-ubuntu/20180411_1129_vdisk1.img
tar: /mnt/user/backup/domains/srv-ubuntu/*.qcow2: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
2018-04-11 11:34 information: finished creating new tarball.
removed '/mnt/user/backup/domains/srv-ubuntu/20180411_1129_srv-ubuntu.xml'
removed '/mnt/user/backup/domains/srv-ubuntu/20180411_1129_bab60192-5d43-b8df-1be5-a7a9c7ab6c7f_VARS-pure-efi.fd'
removed '/mnt/user/backup/domains/srv-ubuntu/20180411_1129_vdisk1.img'
2018-04-11 11:34 information: removing xml, nvram, and image files after tarball.
2018-04-11 11:34 information: backup of srv-ubuntu to /mnt/user/backup/domains/srv-ubuntu completed.
2018-04-11 11:34 information: nubmer of days to keep backups set to indefinitely.
2018-04-11 11:34 information: number of backups to keep set to infinite.
2018-04-11 11:34 information: finished attempt to backup 
srv-ubuntu
to /mnt/user/backup/domains.
2018-04-11 11:34 information: cleaning out logs over 1.
2018-04-11 11:34 information: cleaning out error logs over 10.
find: `/mnt/user/backup/domains/logs/*unraid-vmbackup_error.log': No such file or directory
2018-04-11 11:34 warning: errors found. creating error log file.
sending incremental file list
20180411_1129_unraid-vmbackup.log

sent 4,454 bytes received 35 bytes 8,978.00 bytes/sec
total size is 4,336 speedup is 0.97
2018-04-11 11:34 Stop logging to log file.
2018-04-11 11:34 Stop logging to log file.
Script Finished Wed, 11 Apr 2018 11:34:59 -0400

 

Edited by joelones

Share this post


Link to post

@joelones Sorry for the delay, I somehow missed the notification for this. It does look like everything completed to me as well. The script is throwing an error on the iso file listed here:

2018-04-11 11:30 warning: /mnt/user/kvm/isos/mini.iso of srv-ubuntu is not a vdisk. skipping.

It sees that it is not a vdisk and generates a warning. I can add an option to the next version to ignore iso files.

 

As for the compressed files containing the full path, that is something I was aware of, but just didn't get around to changing before the last update. I am planning on having it compress without the path in the next version.

 

-JTok

Share this post


Link to post

v1.1.3 - 2018/04/16

From Here to Infirmary

 

  • included inline variable to prevent script from running if a parity check is in progress.
  • fixed spelling errors in script.
  • added advanced option to ignore iso files during vdisk check. #UNTESTED
  • fixed so tarballs so files are added without full paths.
  • updated user selectable options so that they only generate a warning in the log, not a full error log file.

 

As always, use at your own risk with no guarantees.

 

Script here: https://github.com/JTok/unraid-vmbackup

 

-JTok

Edited by JTok
formatting

Share this post


Link to post

Just set this script up to run twice a month. Still got some days before the first run, but I set the user variables to log a bunch. I look forward to seeing how it does.

 

How long do you suspect 150GB worth of VM data (all on SSD Cache drives) would take to copy onto an array of standard WD Red HHDs? Just ballpark number of hours?

 

Also, is there a chance to have a User Variable or Feature in the script which disables the Parity Drive during the Backup/Copy process. Then once Backup/Copy is complete, re-enable the Parity Drive. Wouldn't that increase write speeds and therefore decrease the amount of time your VMs have to be down?

Edit: nevermind, I guess that trick only works when you are first setting up UnRAID and need to transfer a bunch of data into the array. Just doing the Parity Check/Writes later instead of On-The-Fly

Edited by Stupifier

Share this post


Link to post

Tried the script this morning all is working except skipping vdisks (vdisks_to_skip)The script hangs.

Renaming the image from .img to .iso on the server and setting ignore_isos to "1" does skip the vdisk if wanted to exclude.

Share this post


Link to post
Tried the script this morning all is working except skipping vdisks (vdisks_to_skip). The script hangs.

Renaming the image from .img to .iso on the server and setting ignore_isos to "1" does skip the vdisk if wanted to exclude.

 

Weird. I am in Spain right now, but I should have some time before next week to run a few tests to see if I can replicate the issue.

Just to make sure, are you putting the full path of the vdisk to skip?

Also, are you able to pm me the log file?

 

Thanks.

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
 
Weird. I am in Spain right now, but I should have some time before next week to run a few tests to see if I can replicate the issue.
Just to make sure, are you putting the full path of the vdisk to skip?
Also, are you able to pm me the log file?
 
Thanks.
 
 
Sent from my iPhone using Tapatalk


Send the log per PM


Sent from my iPhone using Tapatalk

Share this post


Link to post
On 5/9/2018 at 11:29 AM, Stupifier said:

Also, is there a chance to have a User Variable or Feature in the script which disables the Parity Drive during the Backup/Copy process. Then once Backup/Copy is complete, re-enable the Parity Drive. Wouldn't that increase write speeds and therefore decrease the amount of time your VMs have to be down?

Edit: nevermind, I guess that trick only works when you are first setting up UnRAID and need to transfer a bunch of data into the array. Just doing the Parity Check/Writes later instead of On-The-Fly

Right idea, wrong execution. What you are looking for is enabling "Turbo Write" and disabling it again when done. And yes, you can add that into the script.

Share this post


Link to post
Right idea, wrong execution. What you are looking for is enabling "Turbo Write" and disabling it again when done. And yes, you can add that into the script.

Thanks! I was wondering about that after reading the question. I will have to look into implementing that feature.


Sent from my iPhone using Tapatalk

Share this post


Link to post
5 minutes ago, JTok said:


Thanks! I was wondering about that after reading the question. I will have to look into implementing that feature.


Sent from my iPhone using Tapatalk

 

I would need some instruction in order to ADD that into script. But yes, that is what I was going for. Thanks!

Share this post


Link to post

Hello folks, 

 

I have been using this to back up a VM, and a power outage corrupted the VM recently.

 

I copied over the img, but that was insufficient to restore the VM.

I assume this means the configuration is damaged, and while I believe that is part of the backup (the xml file?) I am not sure the proper way to utilize that in the restore process.

 

Can someone aid me in properly restoring from the backup?

Share this post


Link to post
On 5/10/2018 at 2:09 PM, bmdegraaf said:

 


Send the log per PM


Sent from my iPhone using Tapatalk

 

 

I wanted to give a quick update. I was able to replicate this issue, and I have a fix I'm testing. It also led me to the discovery of a couple other specific use case issues that I want to resolve (details below). Once I have all 3 issues resolved I'll post an updated version of the script. I am going to try to include the option to turn on turbo write during backups if I can figure it out quickly enough.

 

The issues I am addressing in the next update:

  1. not skipping vdisks
  2. backups with multiple vdisks when using delta syncing (default) are slow because sometimes the wrong vdisk is chosen (finished backups appear to be correct, but the intermediate steps are done in the wrong order)
  3. number of backups to keep not keeping the correct number with multiple vdisks (i.e. keeping 2 vdisks on a VM with two vdisks will keep 1 copy of each because it counts both towards the total to keep instead of keeping 2 copies of each)

 

-JTok

Edited by JTok

Share this post


Link to post

v1.1.4 - 2018/05/19

A Rose by Any Other Name

 

  • fixed issue with vdisks not being skipped when defined in vdisks_to_skip.
  • fixed incorrect vdisks sometimes being copied before backup when using delta sync with multiple vdisks.
  • fixed wrong number of vdisks being kept when a VM had multiple vdisks attached.
  • added option to automatically enable reconstruct write (a.k.a. turbo write) during backups and then disable after backups complete.

 

I've tested to the best of my ability, but I cannot guarantee everything will work flawlessly. Please be sure to verify your backups are running correctly and let me know of any issues.

 

Script here: https://github.com/JTok/unraid-vmbackup

 

-JTok

Edited by JTok

Share this post


Link to post

Hi JTok,

Thanks for your work on this. I'm setting this up for the first time and was wondering about this warning for backups to keep:

# WARNING: If VM has multiple vdisks, then they must end in sequential numbers in order to be correctly backed up (i.e. vdisk1.img, vdisk2.img, etc.).
number_of_backups_to_keep="0"

I've ended up with two vdisk's with the same number somehow, but in two different locations:

  • /mnt/user/domains/JorgenOSX/vdisk2.img
  • /mnt/disk3/J-VM-vdisk2/vdisk2.img

In my case, will the script not backup both disks in the first place, or will the identical numbering just affect the retention/deletion?

Do I need to rename one of the vdisks to resolve this? This makes me nervous as I don't have a backup yet, catch-22 moment here... :)

Share this post


Link to post
14 hours ago, Jorgen said:

Hi JTok,

Thanks for your work on this. I'm setting this up for the first time and was wondering about this warning for backups to keep:


# WARNING: If VM has multiple vdisks, then they must end in sequential numbers in order to be correctly backed up (i.e. vdisk1.img, vdisk2.img, etc.).
number_of_backups_to_keep="0"

I've ended up with two vdisk's with the same number somehow, but in two different locations:

  •  /mnt/user/domains/JorgenOSX/vdisk2.img
  • /mnt/disk3/J-VM-vdisk2/vdisk2.img

 In my case, will the script not backup both disks in the first place, or will the identical numbering just affect the retention/deletion?

 Do I need to rename one of the vdisks to resolve this? This makes me nervous as I don't have a backup yet, catch-22 moment here... :)

 

Unfortunately having vdisks with the same name wasn't something I took into consideration with the script. Since the both vdisks will be backed up to the same location the second vdisk will overwrite or ignore (depending on which options are used) the first vdisk because the script will think they are the same one.

Renaming one of the disks should be a relatively safe operation, but if you are concerned you could try one of these ways:

1) Make a copy of one of the vdisks manually before renaming it and changing the VM configuration. If you are feeling extra concerned, you may also want to make a copy of the existing VM XML before changing the config to point to the new vdisk name.

2) Run the script with the vdisks_to_skip field filled out for one of the vdisks so that only one gets backed up. Then rename the one vdisk you have a backup of and change the VM configuration.

 

IMPORTANT: You will want to make sure that you rename the disk you're changing to vdisk1.img or the backup script will calculate the retention wrong when using number_of_backups_to_keep.

Edited by JTok
forgot to include naming conventions instructions

Share this post


Link to post
1 hour ago, JTok said:

Unfortunately having vdisks with the same name wasn't something I took into consideration with the script.

Wait, what? I haven't started to use this yet, just haven't gotten motivated, but am I parsing this correctly?

 

Unraid's VM manager creation wizard names all vdisks vdisk1.img and places them in a folder corresponding to the name of the VM. So, I have 10 VM's, 8 of which I created using wizard defaults, so 8 of 10 all have vdisk1.img in their respective folders. The other 2 I played around with, I have a xp.vdi that I moved over from an instance of virtualbox, and another using vdisk2.img because I used the wizard's default vdisk1.img as a scratch drive and since deleted.

 

Are you telling me that all my vdisk1.img files in different folders will create issues with the script?

 

Or is the issue only when you have two image files of the same name and different paths defined for a single VM? Why not use the full path as defined in the XML to reference and backup the disk image files? That way they can be restored along with the XML.

Share this post


Link to post
Just now, jonathanm said:

Wait, what? I haven't started to use this yet, just haven't gotten motivated, but am I parsing this correctly?

 

Unraid's VM manager creation wizard names all vdisks vdisk1.img and places them in a folder corresponding to the name of the VM. So, I have 10 VM's, 8 of which I created using wizard defaults, so 8 of 10 all have vdisk1.img in their respective folders. The other 2 I played around with, I have a xp.vdi that I moved over from an instance of virtualbox, and another using vdisk2.img because I used the wizard's default vdisk1.img as a scratch drive and since deleted.

  

Are you telling me that all my vdisk1.img files in different folders will create issues with the script?

 

Or is the issue only when you have two image files of the same name and different paths defined for a single VM? Why not use the full path as defined in the XML to reference and backup the disk image files? That way they can be restored along with the XML.

 

Ahhh. Sorry, I was unclear. The the vdisk names must be unique per VM, not system-wide. They will be backed up into a folder corresponding with the VM name.

e.g.

/backup_location/VM1/vdisk1.img

/backup_location/VM1/vdisk2.img

/backup_location/VM2/vdisk1.img

/backup_location/VM2/vdisk2.img

 

So with the script as it currently stands, if you have the following vdisks attached to a VM:

/mnt/user/domains/VM1/vdisk1.img

/mnt/disk1/VM1/vdisk1.img

They will both be copied to the /backup_location/VM1/ folder and one will overwrite the other and/or skip it.

 

While I personally prefer a flatter structure for my backups, I like the idea of having the option to backup using the full path. That would resolve the issue with unique names. I will add it to my to-do list for the next version.

 

Share this post


Link to post
42 minutes ago, jonathanm said:

The other 2 I played around with, I have a xp.vdi that I moved over from an instance of virtualbox

 

@jonathanm Are you booting directly to the vdi image, or did you convert it to another format first?


I only ask because since I based this on the original script, it only looks for img and qcow2 files when backing up virtual disks. In hindsight, this is rather fragile, so I think I'll try to switch over to parsing the VM configuration to get the attached disks and their extensions. (Note to self: Also include a blacklist variable so users can exclude extensions they don't want backed up like iso.)

 

Thanks,

    JTok

Share this post


Link to post
1 hour ago, JTok said:

 

@jonathanm Are you booting directly to the vdi image, or did you convert it to another format first?


I only ask because since I based this on the original script, it only looks for img and qcow2 files when backing up virtual disks. In hindsight, this is rather fragile, so I think I'll try to switch over to parsing the VM configuration to get the attached disks and their extensions. (Note to self: Also include a blacklist variable so users can exclude extensions they don't want backed up like iso.)

 

Thanks,

    JTok

Directly booting the vdi. Unraid can use any file valid for KVM, the web wizard is rather limited so you have to manually specify some options. I force installed the virtio drivers to the image while booted in virtualbox, so the transition was painless. If you don't do that, will probably end up with stop errors on windows installs.

 

This may be helpful in your endeavours.

Share this post


Link to post
1 hour ago, JTok said:

I think I'll try to switch over to parsing the VM configuration

This would be best, as file name and extension is not really the best indicator of file type. I can name my vdisk image something.doc and it would probably work as long as it was a properly formatted image file. I don't think kvm parses the name to determine file type, but I could be wrong.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.