joelones Posted March 23, 2018 Share Posted March 23, 2018 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* Quote Link to comment
JTok Posted March 23, 2018 Share Posted March 23, 2018 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. [emoji15] Sorry about that. Sent from my iPhone using Tapatalk Quote Link to comment
PieQuest Posted March 23, 2018 Share Posted March 23, 2018 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! Quote Link to comment
JTok Posted March 27, 2018 Share Posted March 27, 2018 (edited) 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 March 27, 2018 by JTok Quote Link to comment
joelones Posted April 11, 2018 Share Posted April 11, 2018 (edited) @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 April 11, 2018 by joelones Quote Link to comment
JTok Posted April 13, 2018 Share Posted April 13, 2018 @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 Quote Link to comment
JTok Posted April 17, 2018 Share Posted April 17, 2018 (edited) 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 April 17, 2018 by JTok formatting Quote Link to comment
Stupifier Posted May 9, 2018 Share Posted May 9, 2018 (edited) 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 May 9, 2018 by Stupifier Quote Link to comment
bmdegraaf Posted May 10, 2018 Share Posted May 10, 2018 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. Quote Link to comment
JTok Posted May 10, 2018 Share Posted May 10, 2018 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 Quote Link to comment
bmdegraaf Posted May 10, 2018 Share Posted May 10, 2018 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 TapatalkSend the log per PMSent from my iPhone using Tapatalk Quote Link to comment
JonathanM Posted May 11, 2018 Share Posted May 11, 2018 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. 1 Quote Link to comment
JTok Posted May 11, 2018 Share Posted May 11, 2018 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 Quote Link to comment
Stupifier Posted May 11, 2018 Share Posted May 11, 2018 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! Quote Link to comment
Ruthalas Posted May 14, 2018 Share Posted May 14, 2018 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? Quote Link to comment
JTok Posted May 17, 2018 Share Posted May 17, 2018 (edited) 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: not skipping vdisks 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) 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 May 17, 2018 by JTok 1 Quote Link to comment
JTok Posted May 19, 2018 Share Posted May 19, 2018 (edited) 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 May 19, 2018 by JTok 1 Quote Link to comment
bmdegraaf Posted May 19, 2018 Share Posted May 19, 2018 Hi JTok, can confirm that all is working as expected! Many thanks! Quote Link to comment
Jorgen Posted May 20, 2018 Share Posted May 20, 2018 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... Quote Link to comment
JTok Posted May 20, 2018 Share Posted May 20, 2018 (edited) 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 May 20, 2018 by JTok forgot to include naming conventions instructions Quote Link to comment
JonathanM Posted May 20, 2018 Share Posted May 20, 2018 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. Quote Link to comment
JTok Posted May 20, 2018 Share Posted May 20, 2018 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. Quote Link to comment
JTok Posted May 20, 2018 Share Posted May 20, 2018 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 Quote Link to comment
JonathanM Posted May 20, 2018 Share Posted May 20, 2018 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. 1 Quote Link to comment
JonathanM Posted May 20, 2018 Share Posted May 20, 2018 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. Quote Link to comment
Recommended Posts
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.