Elmojo

Read back through the past couple pages at least. You appear to be having the exact same issue as me. Hopefully someone will jump in to help us.

Thanks so much, very helpful! I was misunderstanding the key thing. I thought the template was asking me to input the key. I see now that it's just a parameter flag. I'll read through the docs and see if I can get the ports forwarded. I use pfsense, and haven't done any forwarding in a long time.

Thanks for the quick reply, but I'm afraid I'm gonna need a little more than that. Your confidence in my abilities is a little overrated, sadly. lol Forward which ports? All of them? There appear to be 6 ports listed in the template. Forward them to where? What private key? Do I start the container, look at the log to get the key, then stop it, edit the template, and start it again? That doesn't seem likely, but it's all I can think of right now... This is all probably quite obvious to some folks, but I feel like I'm still learning the basics after 3+yrs of running unraid.

Interested in RustDesk server. Not super sure where to start. Reading this 148 page thread doesn't seem like the best use of my time.... lol Any suggestions on a good walkthrough on using this docker to set up RustDesk self-hosted?

How do I go about tracking down what that activity might be? Is there a tracer app that will tell me what processes access which devices? If so, that sounds like it might be something a little beyond my abilities to interpret... lol

Indeed. root@Tower:~# sdparm -C sense /dev/sdn /dev/sdn: SEAGATE ST6000NM0014 MB84 Additional sense: Standby condition activated by command They spin down, but you see in the attached screen that sdj, sdk and sdn have already spun right back up!

SDJ-SDN are the ZFS pool that won't seem to stay down. SDO-SDZ are also a ZFS pool, but those are in an external enclosure, and oddly seem to be working fine. The difference, I think, is that the first pool are Seagate drives. Bummer about the SMART, I thought I had it figured out... lol Here's the whole rundown, if that helps...

1. Yes, I do appear to be seeing some of those. Not sure which drives those msgs apply to, though. I can track them down by dev code if you want. Feb 24 08:41:52 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdk Feb 24 08:42:11 Tower emhttpd: spinning down /dev/sdl Feb 24 08:42:11 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdl Feb 24 08:42:30 Tower emhttpd: spinning down /dev/sdm Feb 24 08:42:30 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdm Feb 24 08:43:33 Tower emhttpd: read SMART /dev/sdj Feb 24 08:43:46 Tower emhttpd: read SMART /dev/sdk Feb 24 08:43:58 Tower emhttpd: read SMART /dev/sdl Feb 24 08:44:10 Tower emhttpd: read SMART /dev/sdm Feb 24 08:48:21 Tower emhttpd: spinning down /dev/sdn Feb 24 08:48:22 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdn Feb 24 08:49:20 Tower emhttpd: read SMART /dev/sdn Feb 24 09:19:22 Tower emhttpd: spinning down /dev/sdn Feb 24 09:19:22 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdn Feb 24 09:19:40 Tower emhttpd: read SMART /dev/sdn 2. Yes, I see the SAS assist line there as well. And I see that it's the same devices as above. I guess that means it's working, but something is waking up the pool? There's absolutely nothing on those drives yet, I wonder what could be waking it...? Feb 24 09:43:06 Tower emhttpd: spinning down /dev/sdn Feb 24 09:43:06 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdn Feb 24 09:43:24 Tower emhttpd: spinning down /dev/sdj Feb 24 09:43:24 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdj Feb 24 09:43:43 Tower emhttpd: spinning down /dev/sdk Feb 24 09:43:43 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdk Feb 24 09:44:01 Tower emhttpd: spinning down /dev/sdl Feb 24 09:44:01 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdl Feb 24 09:44:20 Tower emhttpd: spinning down /dev/sdm Feb 24 09:44:20 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdm AHA!! I just watched the log, and when it read the SMART codes for those drives, they woke up. That appears to be the culprit...maybe? Feb 24 09:44:57 Tower emhttpd: read SMART /dev/sdj Feb 24 09:45:10 Tower emhttpd: read SMART /dev/sdk Feb 24 09:45:22 Tower emhttpd: read SMART /dev/sdl Feb 24 09:45:34 Tower emhttpd: read SMART /dev/sdm Feb 24 09:45:46 Tower emhttpd: read SMART /dev/sdn 3. Sure... root@Tower:~# ls -la /dev/disk/by-path total 0 drwxr-xr-x 2 root root 1080 Feb 18 17:10 ./ drwxr-xr-x 7 root root 140 Feb 18 17:09 ../ lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:00:1d.0-usb-0:1.4:1.0-scsi-0:0:0:0 -> ../../sda lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:00:1d.0-usb-0:1.4:1.0-scsi-0:0:0:0-part1 -> ../../sda1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:0:0 -> ../../sdb lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:0:0-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:10:0 -> ../../sdl lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:03:00.0-scsi-0:0:10:0-part1 -> ../../sdl1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:11:0 -> ../../sdm lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:03:00.0-scsi-0:0:11:0-part1 -> ../../sdm1 lrwxrwxrwx 1 root root 9 Feb 24 04:40 pci-0000:03:00.0-scsi-0:0:12:0 -> ../../sdn lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:03:00.0-scsi-0:0:12:0-part1 -> ../../sdn1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:1:0 -> ../../sdc lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:1:0-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:2:0 -> ../../sdd lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:2:0-part1 -> ../../sdd1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:3:0 -> ../../sde lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:3:0-part1 -> ../../sde1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:4:0 -> ../../sdf lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:4:0-part1 -> ../../sdf1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:5:0 -> ../../sdg lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:5:0-part1 -> ../../sdg1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:6:0 -> ../../sdh lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:6:0-part1 -> ../../sdh1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:7:0 -> ../../sdi lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:7:0-part1 -> ../../sdi1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:8:0 -> ../../sdj lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:03:00.0-scsi-0:0:8:0-part1 -> ../../sdj1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:9:0 -> ../../sdk lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:03:00.0-scsi-0:0:9:0-part1 -> ../../sdk1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy24-lun-0 -> ../../sdo lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy24-lun-0-part1 -> ../../sdo1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy25-lun-0 -> ../../sdp lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy25-lun-0-part1 -> ../../sdp1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy26-lun-0 -> ../../sdq lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy26-lun-0-part1 -> ../../sdq1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy27-lun-0 -> ../../sdr lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy27-lun-0-part1 -> ../../sdr1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy28-lun-0 -> ../../sds lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy28-lun-0-part1 -> ../../sds1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy29-lun-0 -> ../../sdt lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy29-lun-0-part1 -> ../../sdt1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy30-lun-0 -> ../../sdu lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy30-lun-0-part1 -> ../../sdu1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy31-lun-0 -> ../../sdv lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy31-lun-0-part1 -> ../../sdv1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy32-lun-0 -> ../../sdw lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy32-lun-0-part1 -> ../../sdw1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy33-lun-0 -> ../../sdx lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy33-lun-0-part1 -> ../../sdx1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy34-lun-0 -> ../../sdy lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy34-lun-0-part1 -> ../../sdy1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy35-lun-0 -> ../../sdz lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy35-lun-0-part1 -> ../../sdz1

So I have a bunch of drives, all SAS. My array spins down fine (using this plugin), as do the drives in my external MD1200 disk shelf. However, my internal ZFS pool, which are Seagate drives (I see issues noted above), are not spinning down at all. I've scanned the last page or so, and didn't see a solution. Is there any way to get them to calm down, or am I stuck with 5x drives running forever? I did discover that I can manually spin down that pool from the Main tab. I never saw that option before. When I do that, the drives show the little green "working" symbol, but they never go gray until I leave the page and come back. That does seem to work, though. Any thoughts?

I did start reading the first few pages, but saw that it was just bug reports and squashing, as you noted, so maybe I need to skip ahead a little and read the rest. I don't know when I'll get time for that, but I'll add it to the 'to do' list. Have you run into any issues with backups being very slow on local LAN? Is that addressed somewhere in those 18 pages? lol

I could, but even if that works, I don't think the resultant file would be of any use to me, since my goal is to be able to mount the VHD backup in VMWare or some other virtualization environment as an option. In most cases, I would probably just restore the image back to the original VM, but I'd like the option to be able to mount the image in Windows or whatever, if I need to just pull a few keys files.

That sounds about right. I'm not sure why mine is running so slow. The rest of my network is plenty fast. In fact, the very first backup I ran seemed to be pretty quick. I wonder if it's because I'm using the "uncompressed" file format? I wouldn't think so, but anything is possible. Hopefully, @binhex (does tagging not work here?) or someone who knows more about how this docker works under the hood can chime in and offer some suggestions.

There is no ISO backup. An ISO is a disc image, like of a CD or DVD. This software makes images of hard drives, containing operating systems (it also does file backups, but we're discussing full disk imaging), that can later be mounted as virtual machines. In the context of unraid, we will most likely be essentially backing up a VMD (Virtual Machine Disk) to a VMD, rather than backing up a physical disk to a VMD, like you'd be doing if you were running this software on a regular computer.

Not exactly. You get a virtual hard drive image. It's an exact replica of the drive, in file form. You can mount that image back into a VM (which is how it was before the crash), or you can mount it in another software (as a drive letter in Windows, for example), if you only want to extract data from the image, and not actually boot it again.

No, I just installed it today. I have no idea what the restore process is. I'm actually more concerned with getting the actual backups to work properly before I worry about restoring them. lol

Yeah...something is amiss... lol With my setup, I mean.

Has anyone experienced very sloooow image backups? I'm backing up my VMs, and the images are only about 50-60GB in size. The transfers over my local network are running at about 15-20Mbps, which means they take 5-7 hours to run. I'm using the uncompressed (VHD) image type, so that I can (hopefully) mount an image in Windows or VMWare in the case of a VM corruption. Is this a bad idea? I'm brand new to this software, so I'm likely doing things bass-akwards. Suggestions appreciated! I also notice that one of my VMs seems to be running the backups pretty much continuously, even though I have it on the default 7-day schedule. Is that a known issue?

I have similar questions, but we're probably better off asking in the support thread for URBackup, so we don't pollute this thread. See you there!

Yes, I know, thanks. I'm trying to determine if I can get away with using this docker and self-hosting, or if I need to just through all the hoops required to get the physical UDM playing nice with my pfsense box. So far, I'm not having much success either way. Actually, that doesn't quite seem to be the case. I have only 1 U6 Pro AP adopted, and I now have all the icon categories along the far left available, and under settings, I have WiFi, Networks, and System. However, the wifi isn't really working. My phone says it "can't connect", but the Unifi dashboard is reporting that my phone is indeed connected with a "good (70%) experience", which is really worrying, since the AP is sitting about 8 feet away from my phone. If this is the type of "experience" I can look forward to with Unifi devices, they may not be for me. I realize I'm likely doing something (or many things) wrong, but this all just seems far more difficult than it should be. Running the Unifi controller software behind one of the world's most popular router/firewall software should be a well-documented process. It baffles me that I'm having such a hard time finding clear, step-by-step tutorials for how to make it happen. Sorry for the rant, it's been a rather frustrating couple days... EDIT: Got it (kinda) working. It had prompted me to create a new network, but that wasn't working, so I deleted it and changed the wifi back to use the "default" network, and that seems to be working, sorta. It will drop the connection on my phone randomly, but at least it's connecting now. I'll investigate more later...

I don't. My switch is a managed TP-Link POE+. It sounds like I might only have the WiFi tab. Oh well. Better than nothing. Anyone wanna buy a UDM-Pro with 3TB HDD, like new? lol

So what's the deal, is this plugin defunct or what? My unraid just flat refuses to install it anymore. I'm on 6.12.8. If I go to the plugins page and click the "Plugin file install errors" tab, it shows vmbackup.plg as status:error, with no explanation. My only option is [delete]. Anyone found a way to get it working? I'd really like to have backups of my VMs....

Oh okay, so that's normal to not have the "network" tab? I was thinking that in the video from Lawrence systems, it showed that tab as available. I might need to go back and watch again. Thanks for the help!

The Unifi Controller webUI. I'm logged in, but it's mostly unavailable. It's telling me that I don't have internet, or access to any of the network or WiFi screens, because nothing is connected. I understand the WiFi part, since I have no APs connected yet. The rest I don't understand. How do I connect this controller (docker) to my network, is basically what I'm asking. See the screenshots.

Now he tells me! lol Ok, so it's back up, and I'm in the webUI, but I still have the same screens. Most everything is shaded out and unavailable. It says I need a gateway...

Gotcha! Yep, pfsense is handling DHCP duties. I assigned an IP outside the range and applied. Now, when I start the docker and launch the webUI, I get a blank screen with "about:blank#blocked" in the address bar. EDIT: The logs are totally blank, but the console appears to be running.