• Posts

  • Joined

  • Last visited

Everything posted by UncleStu

  1. I keep getting the warning about the following files/folders may not be accessible to SMB shares. While I was setting up Nextcloud, I had the SMB share set to yes. However I have since changed this to no. I've tried enabling it again, and disabling. I even changed the permissions of the root directory for nextcloud to match my other shares. I have run Docker Safe New Perms several times as well. I cannot seem to figure out how to clear this warning. Any ideas? Other than just excluding the directory from Fix Common Problems?
  2. I ran a test backup after the updates to Unassigned Devices and no other changes. The backup completed just fine. The only difference this time was that I powered off my VM manually vs. letting the script do it. I want to test this more as it appeared to copy my previous backup file to the current date and then actually backup the VM to the new dated file as well. It definitely took longer and the logs read funny. I/E: (My recollection of the logs, I don't have access to them at the moment.) Copying backup VMimage_01-31-2020 to VMimage_02-05-2020 started. Copying backup VMimage_01-31-2020 to VMimage_02-05-2020 completed. Copying VMimage to VMimage_02-05-2020 started. Copying VMimage to VMimage_02-05-2020 completed. The good news though is that it finished with no errors.
  3. Sweet. I'm all in for the change. I'll also test my backups again since the update to the Unassigned Devices plugin. I'll also create a new unRAID share and test backing up there. Ideally I would like the VM backups off box though.
  4. I like the cleaner file structure, but would not want to lose the ability to clean up my older backups. Thinking out loud here. Could you take a listing of the folders within the backup directory and convert that to a date or variable to use? Say the backup location is /mnt/user/backups and then the VM Backup app creates dates as directories from there. I know within Linux you can get a listing of files or directories that are older than X days. Is there a way to generate this list on the fly and then purge out old directories that are older than X? Within the app the user can define the value for X.
  5. 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
  6. 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/ 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/ 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/ 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/ failed. 2020-01-30 18:35 information: backup of vdisk1.img vdisk to /mnt/disks/ 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/ completed.
  7. Since my upgrade to 6.6.6, this is occuring on my server too. Although it is nearly weekly, and so far only around 7 AM. My server locked up on Dec 12th and again today, Dec 18th. There is no diagnostics logs or anything in the syslog file to help pinpoint why. Pressing the power button does not initiate a shutdown and the console is completely frozen too. I am forced to power cycle it to get the server back online. I just kicked off a tail of the syslog to a text file, so in the event of the next lock up, hopefully I will catch something. Short of reverting back to 6.6.5, is there anything else that may help find the root of the issue?