VM Backup Plugin


Recommended Posts

5 minutes ago, Dati said:

Sorry, what a stupid mistake! I haven't read the error message correctly. I've just looked into the file /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php

The problem was a paranthesis. It was my mistake!

It's not your fault. It should work honestly, but it seems to be an issue with parse_ini_file in PHP as far as I can tell. I'm trying to find a workaround, but have been unsuccessful so far.

At the very least, I'll try to make it clear they are causing an issue in a future update. At least until I can get it resolved.

Link to comment
5 hours ago, JTok said:

Sorry, I wasn't clear. My tests were from an SSD cache array to the Parity Array. So that's also the bottleneck I was referring to.

I was attempting to also point out that, to anyone interested in improving throughput, the biggest improvements will come from changing storage around to cut out the Parity Array. i.e. running the VMs on an NVMe unassigned device and backing up to an SSD cache array or vice versa.

Yep, that makes sense.  I hadn't really considered backing up directly to the cache tier because for a lot of people that means their VMs and backups are on the same storage device(s) and it could fill up the cache quickly and add a lot of wear to the SSDs.  In thinking about it, I agree that backing up to a share that has cache: Yes, cache: Prefer, or cache: Only would definitely help with the I/O performance bottleneck.  But I think the script would still be doing things a bit inefficiently (including wearing out the cache faster) and would still be slower than inline compression.

 

5 hours ago, JTok said:

This seems viable, but there are some issues that I would need to handle related to backwards compatibility before switching compression algorithms outright.

Yes, I agree that backwards compatibility would be nice to maintain.  My suggestion is to introduce a new option that, when set performs inline zstd compression, but when not set still behaves like before.

 

5 hours ago, JTok said:

I'm going from memory here, so possibly the details are wrong, but I believe it came down to being able to turn the VM back on sooner.

That makes sense.  I think a large part of the point of zstd compression, however, is that most modern processors can easily handle real-time compression.  So, technically it will be faster to do inline compression because the bottleneck will still usually be I/O, but the amount of data that even needs to be written will usually be reduced.

5 hours ago, JTok said:

Thanks for looking into this btw!

Yep, no problem.

 

Here is a preliminary pull request to your script only GitHub repo: https://github.com/JTok/unraid-vmbackup/pull/23/files?utf8=✓&diff=split&w=1

 

I still need to finish some testing (i.e. I have no idea what will happen with snapshots enabled), as well as implement the removal of old .zst archives based on age or count limits, but the base code seems to be working well on my test system.

 

My current test VM is a single vdisk Windows 10 image, 30GB raw, 8 GB sparse, and compresses down to about 6.2GB.  With the old compression turned on it took between 2-3 minutes to copy the 8 GB sparse vdisk over to the array (from a NVMe cache tier), and about 8 minutes to compress it.  With the new compression turned on, it took between 1-2 minutes to perform the inline compression over to the array and then it was done.  The CPU usage was marginally higher, but in either case the primary bottleneck was array I/O (turbo write enabled).  This is running on my test UnRaid server which has a 4th Gen quad-core CPU (with not much else going on) and a 2x 2.5" 500 GB disk single parity array (writes cap out at around 80-90 MB/s).  Obviously results will vary depending on other hardware configs and VM disks.  I have .log files if interested.

 

Link to comment
57 minutes ago, sjerisman said:

My current test VM is a single vdisk Windows 10 image, 30GB raw, 8 GB sparse, and compresses down to about 6.2GB.  With the old compression turned on it took between 2-3 minutes to copy the 8 GB sparse vdisk over to the array (from a NVMe cache tier), and about 8 minutes to compress it.  With the new compression turned on, it took between 1-2 minutes to perform the inline compression over to the array and then it was done.  The CPU usage was marginally higher, but in either case the primary bottleneck was array I/O (turbo write enabled).  This is running on my test UnRaid server which has a 4th Gen quad-core CPU (with not much else going on) and a 2x 2.5" 500 GB disk single parity array (writes cap out at around 80-90 MB/s).  Obviously results will vary depending on other hardware configs and VM disks.  I have .log files if interested.

 

And here is another test that is closer to real world (and even more impressive)...

 

I took a 'real' Windows 7 VM with a 20 GB raw sparse img file (18 GB allocated) and ran it through the old and new compression code.

 

With the old compression code, it took 3-4 minutes to copy the 18 GB image file from a NVMe UD over to a HDD dual-parity array, and then another 14-15 minutes to .tar.gz compress it down to 8.4 GB.

 

With the new inline compression code, it only took 2-3 minutes to copy from the NVMe UD and compress (inline) over to the HDD dual-parity array with a slightly smaller 8.2 GB compressed output size.  The CPU usage was marginally higher than during the .tar.gz step but was over much quicker.

Link to comment

And, I repeated the same Windows 7 'real' VM test one more time, but this time used the SSD cache tier as the destination instead of the HDD...

 

With the old compression code, it took 1-2 minutes to copy the 18 GB image file from the NVMe UD over to the dual SSD cache, and then still took 13-14 minutes to further .tar.gz compress it down to 8.4 GB.  The compression step definitely seems CPU bound (probably single threaded) instead of I/O bound with this test.

 

With the new inline compression code, it still only took about 1-2 minutes to copy from the NVMe UD and compress (inline) over to the dual SSD cache and still produced a slightly smaller 8.2 GB output file.  The CPU was definitely hit harder, and probably became the bottleneck (over I/O), but I'm really happy with these results and would gladly trade off higher CPU for a few minutes for much lower disk I/O, much less disk wear, and much faster backups.

Link to comment

@JTok - I was able to do some more coding and testing on my open pull request: https://github.com/JTok/unraid-vmbackup/pull/23/files?utf8=✓&diff=split&w=1

 

Additional changes:

* I added seconds to the generated timestamps and logged messages for better granularity

* I refactored the existing code that deals with removing old backup files (both time based as well as count based) to make it more consistent and easier to follow

* I added support for removing old .zst archives (both time based as well as count based) using the refactored code above

* I did a bunch of additional testing (including with snapshots on) and I think everything is working properly

 

Let me know if you would like to see any other changes on this PR.  I can make a similar PR for the GUI/Plugin version after this one is approved and after I figure out how to properly test changes to the GUI/Plugin.

Link to comment
On 1/8/2020 at 8:37 PM, JTok said:

I looked into this a little today, but this is by no means conclusive. In my tests so far I/O has been the biggest bottleneck, not the compression algorithm or number of threads. So using the parity array vs the cache array, or an unassigned device, is probably going to have the biggest effect on performance.
Honestly, all things being equal, I only saw about a 15-20% performance improvement with my test VM (though I understand that there could be more pronounced differences with other use cases). I tested using zstd, lbzip2, and pigz.

That being said, since there are some performance improvements with a multi-threaded compression utility, I am looking into a good way to integrate something.
I suspect, that at least initially, I will stick with pigz because of backwards compatibility issues. Though I may look into adding an option for the other two later on.

Thanks for looking into it!

 

I just read the whole thread.

Thanks to @sjerisman as well.

Compression looks promising

Edited by nextgenpotato
Link to comment

Thanks for an awesome plugin! Probably a dumb question and apologies if this is clear or explained elsewhere: my question is under the 'Set backup location' - is there support for remote file shares like a NAS drive? I tried setting up a backup to a NAS drive that I have with SMB file share access at \\192.168.1.2\VMs. Could this be something that could be developed to work - if not are there better tools do this?

 

Thanks

Link to comment
Thanks for an awesome plugin! Probably a dumb question and apologies if this is clear or explained elsewhere: my question is under the 'Set backup location' - is there support for remote file shares like a NAS drive? I tried setting up a backup to a NAS drive that I have with SMB file share access at \\192.168.1.2\VMs. Could this be something that could be developed to work - if not are there better tools do this?

 

Thanks

 

I’m out of town this weekend and away from my server, so I’m not sure if there’s a better way (or if this is easily accomplished in unraid)... but off the top of my head, can you mount the share locally in unraid first, then backup to the mount point?

 

 

Sent from my iPhone using Tapatalk

Link to comment

My apologies for long delay since the last release, for those that care about why, I'll leave it in the postscript.

 

In this version there are some major changes in addition to the usual bug fixes. A big bug fix, is that the plugin should now be able to handle parenthesis in your VM names (thanks to squid for suggesting a solution to that).

New features include the ability to have multiple configs so that you can run backups on different schedules, as well as the ability to run pre and post scripts with those configs. Compression now uses pigz for multi-threaded compression (though a faster inline compression using zstandard is still coming).

Full change-log below.

 

 

v0.2.0 - 2020/01/21
The Resistance

- fixed new config options not always getting added to user config.
- fixed parenthesis in vm names.
- added ability to run pre and post scripts.
- added option to run backup without array started.
- added confirmation dialogs to destructive or dangerous buttons.
- added support for multiple configs/schedules.
- added option to allow multiple configs to run simultaneously.
- added option to set compression level.
- added option to set the number of threads used during compression.
- changed compression program from gzip to pigz to support multi-threading.
- changed alert dialogs to use sweet alerts.
- updated help for custom cron.

 

https://github.com/JTok/unraid.vmbackup/tree/v0.2.0

 

-JTok

 

The delay in this release was caused by me overhauling some of the code to prevent the pages from needed refreshed to update content, and I wound up needing to implement my own version of unRAID's markdown and inline-help to make that work the way I wanted.

Edited by JTok
  • Like 4
Link to comment

Thanks for a great update.  I'm not sure if the multi-config is working though.  Here's what I did to try and create a new config for my pfsense VM based on my W10 config:

 

1. created config for W10 - saved and created config name

2. created copy and called if pfsense

3. tried to go and change the VMs to backup for pfsense config, but it won't let me change

 

Also, oddly it lets you select multiple configs to edit - shouldn't it be only one to edit?

 

Thanks

Link to comment

@DZMM

You create and manage the configs on the Manage Configs tab, but to edit them you choose the "current config" from the drop-down box on the Settings tab. From there you edit the config like normal. When you want to edit a different config, you go back to the drop-down box on the Settings tab.

 

Also, default config cannot be renamed or removed, and will not show up on the Manage Configs tab. So you already start with that config active, but from the Manage Configs tab you can add/edit additional configs.


In retrospect, it isn't very obvious how it works, so I'll make some adjustments in the next version.

Edited by JTok
added info default config info
Link to comment

@JTok AHH found it - yeah it really needs to be at the top of the page.

 

 Creating a profile should be the first thing done, and an option to start it with the current settings or to use the default settings.  I was surprised to see I had 3 profiles (default, w10 and pfsense) to choose from on the front page when I'd only created two.  Hope that makes sense.

 

Link to comment
14 minutes ago, DZMM said:

Creating a profile should be the first thing done, and an option to start it with the current settings or to use the default settings.  I was surprised to see I had 3 profiles (default, w10 and pfsense) to choose from on the front page when I'd only created two.  Hope that makes sense.

I get what you're saying, but I don't want to make creating a profile necessary to get started... or going to any other tabs for that matter.

I want it to be as close to working out of the box as possible, with as few fields as possible to fill in to get started, and all of them in the same place.

 

To give you an idea of where my head is at, my design philosophy is that the main tab (i.e. Settings tab) is the only tab you actually need to have a basic functioning backup with reasonable settings. The other tabs are for more advanced configurations that a basic user really may not need. A user shouldn't have to go to any of the other tabs unless they want to explore. I'm trying to avoid intimidating non-technical users because the technical ones will go exploring anyway.

I understand that this may not be ideal for every user and situation, but I would prefer to cater to the lowest common denominator and have the plugin be accessible to as many users as possible instead of throwing a wall of options at everyone and forcing them to sort through it.

 

All of that is a big reason why you started with a 'default' config. The other, more practical reason, is backwards compatibility. Everyone with a previous version of the plugin had an existing config that needed to go somewhere, and I don't think anyone would have been thrilled with me if an update wiped it out 😅

 

 

Again though, I absolutely agree that configs are very confusing in their current form, so I have already made some small changes to the upcoming version that should help clear up how the configs work some for new users, and I will keep refining it as we move forward.

 

 

14 minutes ago, DZMM said:

@JTok AHH found it - yeah it really needs to be at the top of the page.

I may move it to a different place at some point when the plugin state is a bit more stable, but for now I'm considering it an Advanced Setting and going to leave where it is. More or less for the reasons above. (Although I have some ideas on where to move it later once things are stable.)

 

14 minutes ago, DZMM said:

and an option to start it with the current settings or to use the default settings.

I'm not exactly sure what you mean by this? 🤔

 

Link to comment
36 minutes ago, JTok said:

I'm not exactly sure what you mean by this? 🤔

 

yeah I was worried I wasn't making sense - I'd just woken up!  What I was trying to say (hopefully better this time!) is that when you create a profile, it'd be useful if there was an option to 'use current settings'.  I thought this was the behaviour when I'd tweaked all my settings and then got to the last tab and created my first profile 'w10' - I thought it was saving my current settings to w10, rather than creating a new profile alongside the existing default profile.

 

The Default button on the first tab needs to say something like 'create new profile' as that's what it does currently i.e. load blank settings, not the default profile that any initial changes are saved to.  i.e. if I on first run make changes and don't create as a new profile then those settings are saved to the 'default profile' but clicking the 'Default' button doesn't load those settings, but resets all.

 

Update: clicking the Default button actually reset my 'default' profile not loaded my defaults so it's really a Reset button.  It also applied the reset rather than letting me review, so it wiped out my settings

Edited by DZMM
Link to comment
yeah I was worried I wasn't making sense - I'd just woken up!  What I was trying to say (hopefully better this time!) is that when you create a profile, it'd be useful if there was an option to 'use current settings'.  I thought this was the behaviour when I'd tweaked all my settings and then got to the last tab and created my first profile 'w10' - I thought it was saving my current settings to w10, rather than creating a new profile alongside the existing default profile.

I see what you mean, I’ll try to find a way to make this clearer and/or more intuitive.

 

The Default button on the first tab needs to say something like 'create new profile' as that's what it does currently i.e. load blank settings, not the default profile that any initial changes are saved to.  i.e. if I on first run make changes and don't create as a new profile then those settings are saved to the 'default profile' but clicking the 'Default' button doesn't load those settings, but resets all.

 

Update: clicking the Default button actually reset my 'default' profile not loaded my defaults so it's really a Reset button.  It also applied the reset rather than letting me review, so it wiped out my settings

This is the design paradigm used by the rest of unRAID, so I don’t think it is a good idea for me make my plugin the exception as that could cause further confusion. The functions of those buttons are defined by the plugin system, and while I’ve bypassed those default functions to implement them in a specific way, I kept the basic functionality the same for consistency across all the other plugins/forms.

 

Here is a breakdown of how the buttons work by default in unRAID:

The Default button resets the form to defaults. The Apply button submits the form. The Done button takes you out of the current plugin/screen. The Done button also changes to Reset if something on the form has been altered but the Apply button hasn’t been hit yet. When it is a Reset button, it will reset the changes in the form back to the last saved settings.

 

 

Also, you should be getting a warning pop up when you hit the Default button asking you if you are sure you want to reset to Defaults.

 

 

 

Sent from my iPad using Tapatalk

Link to comment
2 minutes ago, JTok said:



Also, you should be getting a warning pop up when you hit the Default button asking you if you are sure you want to reset to Defaults.
 

Hmm just tested and I saw the popup this time so it all makes sense.  Must have been me - sorry for the false alarm.  Loving the new multi-config and the ability to run concurrently.

Link to comment

Unfortunately it's been failing for me.

The line below seems to be the error, though I've inclluded the full log file.

/tmp/vmbackup/scripts/default/user-script.sh: line 398: vdisk_types["$vdisk_path"]: bad array subscript
2020-01-22 15:14:16 Starting VM Backup for default config.
2020-01-22 15:14:16 PID: 28052
2020-01-22 15:14:16 User script copied to /tmp/vmbackup/scripts/default/user-script.sh
2020-01-22 15:14:16 Running command: '/tmp/vmbackup/scripts/default/user-script.sh' >> '/tmp/vmbackup/scripts/default/20200122_151416_user-script.log' 2>&1
2020-01-22 15:14 information: official_script_name is user-script.sh. script file's name is user-script.sh. script name is valid. continuing.
2020-01-22 15:14 information: enabled is 1. script is enabled. continuing.
2020-01-22 15:14 information: backup_location is /mnt/user/Backup. this location exists. continuing.
2020-01-22 15:14 information: backup_location is /mnt/user/Backup. this location is writable. continuing.
2020-01-22 15:14 information: timestamp_files is 1. timestamp will be added to backup files.
2020-01-22 15:14 information: /mnt/user/Backup/logs/ exists. continuing.
2020-01-22 15:14 information: log_file_subfolder is /mnt/user/Backup/logs/. this location exists. continuing.
2020-01-22 15:14 information: log_file_subfolder is /mnt/user/Backup/logs/. this location is writable. continuing.
2020-01-22 15:14 Start logging to log file.
2020-01-22 15:14 information: send_notifications is 1. notifications will be sent.
2020-01-22 15:14 information: only_send_error_notifications is 0. normal notifications will be sent if send_notifications is enabled.
2020-01-22 15:14 information: unRAID VM Backup script is starting. Look for finished message.
2020-01-22 15:14 information: keep_log_file is 1. log files will be kept.
2020-01-22 15:14 information: number_of_log_files_to_keep is 1. this is probably a sufficient number of log files to keep.
2020-01-22 15:14 information: backup_all_vms is 0. only vms listed in vms_to_backup will be backed up.
2020-01-22 15:14 information: use_snapshots is 0. vms will not be backed up using snapshots.
2020-01-22 15:14 information: kill_vm_if_cant_shutdown is 0. vms will not be forced to shutdown if a clean shutdown can not be detected.
2020-01-22 15:14 information: set_vm_to_original_state is 1. vms will be set to their original state after backup.
2020-01-22 15:14 information: number_of_days_to_keep_backups is 0. backups will be kept indefinitely. be sure to set number_of_backups_to_keep to keep backups storage usage down.
2020-01-22 15:14 information: number_of_backups_to_keep is 2. this is probably a sufficient number of backups to keep.
2020-01-22 15:14 information: compress_backups is 0. backups will not be compressed.
2020-01-22 15:14 information: use_snapshots disabled, not adding snapshot_extension to vdisk_extensions_to_skip.
2020-01-22 15:14 information: snapshot_fallback is 0. snapshots will fallback to standard backups.
2020-01-22 15:14 information: pause_vms is 0. vms will be shutdown for standard backups.
2020-01-22 15:14 information: enable_reconstruct_write is 0. reconstruct write will not be enabled by this script.
2020-01-22 15:14 information: compare_files is 0. files will not be compared after backups.
2020-01-22 15:14 information: backup_xml is 1. vms will have their xml configurations backed up.
2020-01-22 15:14 information: backup_nvram is 1. vms will have their nvram backed up.
2020-01-22 15:14 information: backup_vdisks is 1. vms will have their vdisks backed up.
2020-01-22 15:14 information: start_vm_after_backup is 0. vms will not be started following successful backup.
2020-01-22 15:14 information: start_vm_after_failure is 0. vms will not be started following an unsuccessful backup.
2020-01-22 15:14 information: disable_delta_sync is 0. rsync will be used to perform delta sync backups.
2020-01-22 15:14 information: rsync_only is 0. cp will be used when applicable.
2020-01-22 15:14 information: actually_copy_files is 1. files will be copied.
2020-01-22 15:14 information: clean_shutdown_checks is 20. this is probably a sufficient number of shutdown checks.
2020-01-22 15:14 information: seconds_to_wait is 30. this is probably a sufficient number of seconds to wait between shutdown checks.
2020-01-22 15:14 information: keep_error_log_file is 1. error log files will be kept.
2020-01-22 15:14 information: number_of_error_log_files_to_keep is 10. this is probably a sufficient error number of log files to keep.
2020-01-22 15:14 information: started attempt to backup Windows 10 to /mnt/user/Backup
2020-01-22 15:14 information: Windows 10 can be found on the system. attempting backup.
2020-01-22 15:14 information: removing old local Windows 10.xml.
removed 'Windows 10.xml'
2020-01-22 15:14 information: creating local Windows 10.xml to work with during backup.
2020-01-22 15:14 information: /mnt/user/Backup/Windows 10 exists. continuing.
/tmp/vmbackup/scripts/default/user-script.sh: line 398: vdisk_types["$vdisk_path"]: bad array subscript
2020-01-22 15:14 information: finished attempt to backup Windows 10 to /mnt/user/Backup.
2020-01-22 15:14 information: cleaning out logs over 1.
2020-01-22 15:14 information: removed '/mnt/user/Backup/logs/20200122_1505_unraid-vmbackup.log'.
2020-01-22 15:14 information: cleaning out error logs over 10.
find: '/mnt/user/Backup/logs/*unraid-vmbackup_error.log': No such file or directory
2020-01-22 15:14 information: did not find any error log files to remove.
2020-01-22 15:14 Stop logging to log file.
2020-01-22 15:14:17 Removed: /tmp/vmbackup/scripts/default/user-script.sh
2020-01-22 15:14:17 Removed: /tmp/vmbackup/scripts/default.pid

 

Link to comment

I am getting an error message about the vdisk failing to copy over, yet when I look at the destination location I can see the file there. My backup location set to a NFS mount point on a different NAS and it is successfully mounted via Unassigned Devices. Below is my log for the backup of my domain controller. However I am getting the same error on both VM's when they copy over. My DC is 80 GB and my other VM is 500 GB.

 

Log:

2020-01-30 18:30 information: started attempt to backup DC1, Warden-80_40 to /mnt/disks/192.168.0.107_backup_PCs/unRAID/domains
2020-01-30 18:30 information: DC1 can be found on the system. attempting backup.
2020-01-30 18:30 information: creating local DC1.xml to work with during backup.
2020-01-30 18:30 information: /mnt/disks/192.168.0.107_backup_PCs/unRAID/domains/DC1 does not exist. creating it.
2020-01-30 18:30 information: extension for /mnt/user/isos/virtio-win-0.1.160-1.iso on DC1 was found in vdisks_extensions_to_skip. skipping disk.
2020-01-30 18:30 information: skip_vm_shutdown is false. beginning vm shutdown procedure.
2020-01-30 18:30 infomration: DC1 is running. vm desired state is shut off.
2020-01-30 18:30 information: performing 20 30 second cycles waiting for DC1 to shutdown cleanly.
2020-01-30 18:30 information: cycle 1 of 20: waiting 30 seconds before checking if the vm has entered the desired state.
2020-01-30 18:30 information: DC1 is shut off. vm desired state is shut off. can_backup_vm set to y.
2020-01-30 18:30 information: actually_copy_files is 1.
2020-01-30 18:30 information: can_backup_vm flag is y. starting backup of DC1 configuration, nvram, and vdisk(s).
2020-01-30 18:30 information: copy of DC1.xml to /mnt/disks/192.168.0.107_backup_PCs/unRAID/domains/DC1/20200130_1830_DC1.xml complete.
2020-01-30 18:30 information: DC1 does not appear to have an nvram file. skipping.
2020-01-30 18:35 failure: copy of /mnt/user/domains/DC1/vdisk1.img to /mnt/disks/192.168.0.107_backup_PCs/unRAID/domains/DC1/20200130_1830_vdisk1.img failed.
2020-01-30 18:35 information: backup of vdisk1.img vdisk to /mnt/disks/192.168.0.107_backup_PCs/unRAID/domains/DC1/20200130_1830_vdisk1.img complete.
2020-01-30 18:35 information: extension for /mnt/user/isos/virtio-win-0.1.160-1.iso on DC1 was found in vdisks_extensions_to_skip. skipping disk.
2020-01-30 18:35 information: the extensions of the vdisks that were backed up are img.
2020-01-30 18:35 information: vm_state is shut off. vm_original_state is running. starting DC1.
2020-01-30 18:35 information: vm_state is shut off. start_vm_after_backup is 1. starting DC1.
2020-01-30 18:35 information: backup of DC1 to /mnt/disks/192.168.0.107_backup_PCs/unRAID/domains/DC1 completed.

 

2020-01-30_191542.jpg.449faf24449c29f9e68ad63f3c86829f.jpg

 

Link to comment
On 1/30/2020 at 9:21 PM, UncleStu said:

I am getting an error message about the vdisk failing to copy over, yet when I look at the destination location I can see the file there. My backup location set to a NFS mount point on a different NAS and it is successfully mounted via Unassigned Devices. Below is my log for the backup of my domain controller. However I am getting the same error on both VM's when they copy over. My DC is 80 GB and my other VM is 500 GB.

 

Could you let me know what you have the following set to?

 

Settings:

Enable Snapshots

Compress Backups

 

Other Settings:

Compare files during backup

Disable delta syncs for backups

Only use rsync for backups

 

Danger Zone:

Fall back to standard backups

Pause VMs instead of shutting down

 

Link to comment
On 2/1/2020 at 11:04 PM, JTok said:

Could you let me know what you have the following set to?

Settings:

Enable Snapshots - No

Compress Backups - No

 

Other Settings:

Compare files during backup - No

Disable delta syncs for backups - No

Only use rsync for backups - No

 

Danger Zone:

Fall back to standard backups - No

Pause VMs instead of shutting down - No

Link to comment

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.