Ned

Thank you. I deleted the old snapshots manually via the ZFS snapshots master plugin.

I am using SpaceInvaderOne's script for snapshoting/replication of zfs datasets. It runs on a nightly schedule. The default data retention policy in the script was using too much disk space, so I reduced it from 7 days, 4 weeks and 2 months, to 7 days, 2 weeks and 1 month. However, since I reduced the cadence in the script over a week ago, I have not seen any change in the number of snapshots being stored. My question is, what do I need to do for the old snapshots that no longer fit the new retention policy to be deleted?

Thank you, I freed up some space and re-balanced the pool and after a reboot all is good. Much appreciated!

Woke up this morning and all of my VMs were paused. I forced stopped them and tried to restart them but it said there was no space available. They run off my cache which is a BTRFS pool of two SSDs. The pool has free space, only 391GB used out of 500. I tried running a balance on the pool but it said it wasn't required. Rebooted the server and now my VMs don't even show up in the list nor do my dockers which also ran off the cache. I can still connect to the cache via SMB share and all of the files are there and there does not seem to be any issue accessing or opening them. It does not look like there is any corruption of the data. Any idea what is going on? Diagnostics attached. tower-diagnostics-20230822-0813.zip

So I added in a Broadcomm BCM5751 Gigabit PCIe x1 card. Seems like everything is working fine but this morning I see hundreds of the following entries in the system log... does anyone know what is going on here?? Dec 1 03:53:54 Tower kernel: pcieport 0000:00:02.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) Dec 1 03:53:54 Tower kernel: pcieport 0000:00:02.0: device [8086:6f04] error status/mask=00000040/00002000 Dec 1 03:53:54 Tower kernel: pcieport 0000:00:02.0: [ 6] BadTLP Dec 1 03:54:02 Tower kernel: pcieport 0000:00:02.0: AER: Multiple Corrected error received: 0000:00:02.0 Dec 1 03:54:02 Tower kernel: pcieport 0000:00:02.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) Dec 1 03:54:02 Tower kernel: pcieport 0000:00:02.0: device [8086:6f04] error status/mask=00000040/00002000 Dec 1 03:54:02 Tower kernel: pcieport 0000:00:02.0: [ 6] BadTLP Dec 1 03:54:04 Tower kernel: pcieport 0000:00:02.0: AER: Multiple Corrected error received: 0000:00:02.0 Dec 1 03:54:04 Tower kernel: pcieport 0000:00:02.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) Dec 1 03:54:04 Tower kernel: pcieport 0000:00:02.0: device [8086:6f04] error status/mask=00000040/00002000 Dec 1 03:54:04 Tower kernel: pcieport 0000:00:02.0: [ 6] BadTLP Dec 1 03:54:08 Tower kernel: pcieport 0000:00:02.0: AER: Multiple Corrected error received: 0000:00:02.0 Dec 1 03:54:08 Tower kernel: pcieport 0000:00:02.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) Dec 1 03:54:08 Tower kernel: pcieport 0000:00:02.0: device [8086:6f04] error status/mask=00000040/00002000

My server recently started "pausing" every so often for a few seconds. I first started noticing it when streaming media to my Nvidia shield TV. The media would just freeze (since the data flow from unraid stops during this time) and then a few seconds later it would resume. This can happen several times per hour. Investigating this further, I noticed that if I'm in the web GUI when this happens, the whole GUI locks up. The CPU load bars stop moving, I can't click on anything. I wait about 10 seconds and everything comes back to life. Then I looked in the server log and noticed what looks to be the NIC periodically having "hardware unit hangs". This is the onboard NIC for my Gigabyte X99-UD3P-CF motherboard. I have not tried putting in another standalone NIC yet as I wanted to see if anyone could have a look at the logs first and tell me if the NIC looks to be bad, or if something else could be causing this? I've attached a snippet of the log file for reference. Thank you in advance for any advice! Unraid Log Nov 28.txt

I think I figured it out. I needed to allocate more memory to the crashplan app.

The new CrashplanPRO docker was working fine however halfway through the de-dupe process it is constantly crashing on one particular file/folder it seems. Crashplan keeps restarting. Eventually it says it cannot connect to the backup service. I verified my account and connectivity are ok. Any idea what could be wrong?

Thanks for the quick reply. That's good to hear. The only potential issue I can see with using the plugin is that it doesn't honor split level given the way that it moves the data to disk shares... but that is minor issue I think, especially since once everything is migrated the data could be adjusted between the drives even further if needed.

Ok so I just started to migrate my 10 disks from RFS to XFS and just finished moving data off my smallest disk (as an initial test of the process to make it go quicker) to another disk in my array using the unBALANCE plugin. I have plenty of free space (almost 8TB free) spread across the disks in my array (my largest disk is 4TB) so using this plugin seemed like a very logical way to move my data around between disks without having to do any of the adding/swapping of disks etc. mentioned in the list of instructions posted earlier in this thread. Now I'm reading this thread and seeing this warning - pretty much all of the data on my array is in user shares. However after copying the data from one disk to another using the unBALANCE plugin I then verified that I could access the data I relocated via the user shares from Windows explorer and everything looked good! So I went ahead and formatted the now empty disk to XFS. All looks good as far as I can tell! I was going to repeat this simple process for the next disk but now I am concerned given this warning! My understanding is that the unBALANCE plugin copies data from USER shares to DISK shares... so once the copy procedure is complete, the data that was moved should also show up in the user shares without issue. Am I correct? Is there a PROBLEM with using the unBALANCE command to move data between disks like this? I thought that was the whole point of the plugin? Can someone please confirm that I can continue to migrate my disks to XFS by simply moving the data using the unBALANCE plugin as described and reformatting the disks (as they are emptied) to XFS and that NO OTHER STEPS ARE REQUIRED? Thank you!

Ok thanks for the updates, I will be giving this a go very soon. It's going to be a very long process with 10 disks and over 16TB of data to move around but I'm hearing that the effort is well worth it in the end.

How is parity maintained when you format a disk in the array to a new file system? I'm thinking of migrating my 10 RFS disks to XFS and I have a handle on how to move the data off individual disks so that I can convert them but this is the part I want to be 100% sure of... After the format is complete the array resumes operation with my 10 disks as before? At any time (e.g. during the format process) is the array unprotected?

Great to hear everything went smoothly for you. Hope it will be the same for me!

Thanks everyone!

Like the title says, I'm about to swap out my existing AMD board and CPU with a faster Intel setup. In addition to unraid, I have a couple of dockers and a couple of windows 10 VMs running right now. Do I simply back up my flash, take note of the drive assignments, power down, swap, and power back up? Will the array come back up with the proper drive assignments even though they will be connected to a completely different set of SATA ports on a new motherboard? The CPU I'm putting in is an Intel i7-6800k which will show 12 cores in unraid (6 cores hyperthreaded). My old Phenom II 1055T has 6 cores non-threaded so what will happen to the core assignments for my VMs given the mismatch? Should I set my VMs to not auto-start prior to the upgrade and check the core assignments when I boot up on the new CPU before I re-launch the VMs? Also will the Windows 10 VMs just detect a CPU change and continue to function as normal? Sorry, lots of questions but I just want to make sure there are no gotchas I should be aware of before I make the swap. Thanks!

Hmm I haven't rebooted yet, but this surprises me. The good news is that with docker it is easy to start over. Just delete the container and re-add it. Yes, that's exactly what I had to do to fix it - delete, re-add, and then apply your "fix" again.. I really wish someone would just update the desktop docker already!

I had to reboot my server and now when I run the desktop docker I cannot RDP into it. Docker shows as running but RDP will not connect. I replaced the .ui_info file again but that doesn't help. Do I need to do anything else on a reboot?

Based on those error messages, it sounds like the problem is related to step 1: docker exec -it CrashPlan-Desktop bash If that returned an error message of some kind, then the remaining commands will not work. I've updated the instructions to check for this. That was it... I didn't realize that the desktop docker needed to be running while I executed these commands. Working now, thanks!

When I execute the commands to update the docker I'm having the following issues: 1) cd /usr/local/crashplan I can do cd /usr/local however there is no "crashplan" folder inside the "local" folder? 2) When I run "cat /tmp/crashplan-install/CrashPlan_4.4.1.cpi | gzip -d -c - | cpio -i --no-preserve-owner" it returns: -bash: cpio: command not found What am I doing wrong?

Thanks... I just realized something when I tried this: 1) If you do a /boot to /boot mapping, then when you select show hidden files, your unraid flash shows up in the boot folder. 2) If you do any other mapping to the host /boot (e.g. /unraid_flash to /boot) then you will see that volume mapping in the crashplan desktop app without having to turn on show hidden files... but in this case, if you turn on show hidden files, then the /boot folder appears empty. So, you can do it either way I guess. I went with option 2 only because if I am viewing my crashplan backup from the website or say an iPhone app, it will be easier for me to recognize that the folder contains the unraid flash contents vs a "boot" folder which could seem ambiguous among all of the other folders being backed up. Thanks for the help.

Ok I found the advanced settings slider... This "mapping"... do I do this under the Environment Variables heading and put "/boot" in both the variable name and variable value fields? That doesn't seem right.. Or do I put /boot under both corresponding container volume and host path fields under the volume mappings heading (which does not require advanced settings slider to be toggled)?

Fully aware of those two potential issues but thanks again for pointing them out. From what I understand though, Crashplan is constantly monitoring the file system and if it detects changes it will re-back up those files... so if one were to make a configuration change like that, shouldn't Crashplan notice that change shortly thereafter and back up the new configuration?

Interesting question - I like and am also keen on this. I tried creating a volume mapping to /boot, but that didn't want to work (/boot doesn't even show up in the host path drop down). I created a soft link from /cache/boot to /boot (ln -s /cache/boot /boot). But this, to me at least, is quite a large security risk. It could inadvertently give access to the flash files where you don't want it, especially if /cache is shared. Another option that springs to mind... create a backup folder on either the cache or a disk / user drive. Don't export it and create a cron job to copy all files periodically. Or do this manually each time you upgrade or change anything (which is what I do - each time I upgrade I backup the entire flash drive to my windows file server which is subsequently backed up to CrashPlan anyhow ). UPDATE Seems you can do this: [*]Create a mapping in the advanced settings. I did /boot to /boot, and made it read only. [*]Open the CrashPlan client and click the Change button on the backup tab [*]Check the "show hidden files" checkbox in the client (I'm using the CrashPlan-client via RDP from the host). [*]Once you've done this, all sorts of wonderful folders spring to life. Including /boot. [*]Select it and ok away, presto it is backing up (238 files for 700 MB in my case) Currently backing up boot > bzroot (7.59% @ 2.6Mbps) Glad you were able to figure it out :-) Would you be able to explain where this advanced settings file is and what exactly I need to do to create this mapping?

Is there a way to backup the flash share using Crashplan docker? I figured out that in the Crashplan Desktop docker app, all of the user shares are listed under the "data" folder, including the the appdata, docker.img and other contents of the cache drive... however I have searched through the folder tree and cannot find the flash drive anywhere. Flash is probably the most important content to back up... how can this be done with the Crashplan docker?

I had to do the same thing. Also, after I copied syslinux over and ran make_bootable.bat and then rebooted the server it hung right after the BIOS checks... I check the BIOS and boot settings were still OK and unchanged...after a mild panic attack, I put the flash drive in a different USB slot and then the server booted up just fine. I'd like to know why the system did not like the same USB slot that the flash drive was inserted in before???