JonathanM

NAT Loopback, hairpinning, reflection Search those terms along with your specific model of router.

For planned outages of any length, it's easy to just temporarily stand up your current router for the duration of the maintenance. Hopefully there are no unplanned array stops, I've never had my pfSense VM stop or my array crash, but I am running server grade hardware.

unraid docker. Really??

The link between switches is more important than the server link right now. As drive and media bitrate speeds increase in the future, the server link will become more utilized. It's mostly future proofing, which is what I assumed the point is of having that many drops to begin with. The gamble is, spend the money now and hope the equipment lasts long enough to be fully utilized, or save a chunk now knowing that the equipment will definitely be replaced sooner rather than later. The timeline is uncertain. You asked the best way to connect multiple pieces of network gear designed to serve a single network. Best doesn't usually equal cheapest. Your original layout would work just fine, with all traffic on 1 switch contending with a single link to get to the other switch, or giving up multiple ports on both switches with LACP groups to achieve better cross switch traffic flow. You either buy more ports or faster ports. Changing to a single switch large enough to serve all your devices eliminates that consideration.

No, NFS exposes the full server path.

Is your server directly exposed to the internet? If so, don't. You must put unraid behind a firewall, and only pass through specific ports, preferably only one port pointed to the Let'sEncrypt container running reverse proxy for any other services that need to get through. Never allow direct internet access to unraid's management or console ports.

Perhaps apcupsd hasn't been updated for that model. It's an open source project, not endorsed or supported by APC. http://www.apcupsd.org/ If it bothers you enough to play around, you could try installing NUT from the Apps tab and see if you get better reporting. https://networkupstools.org/

At the console, type apcaccess status and see what the daemon is currently showing.

Looks like 228.0 volts to me in that screenshot.

Ideally yes, you want a POE with a couple 10G ports. When you start actually wiring things up, make sure there is only one port connected initially, as you don't want to form a network loop. However, with the switches you are looking at, I think they would actually detect an issue and down the extra ports until you configured them properly. https://kb.netgear.com/000051185/What-are-link-aggregation-and-LACP-and-how-can-I-use-them-in-my-network

Depends on where the bulk of the traffic is headed. If it's headed out the WAN port, then the router is the obvious choice to connect that specific switch. If it's staying local, then keeping it off the router is better. With the equipment you originally specced out, it really wouldn't make a whole lot of difference. This is the correct answer at this point in time for your layout IMHO. A single unit feeding all data lines, with uplink ports connecting to the POE branch. Now all you need is a real router and some Unifi access points hanging off that POE switch along with your cameras and you have a small office capable network.

I just realized, I answered the question you asked in the body of the message, and totally ignored the title. The best way to connect multiple switches is to be sure you get models that are meant to be connected and work with each other, the term you are looking for is stackable. Since you said you already purchased the equipment that doesn't have that feature, then all the traffic that must traverse between the switches will be bottlenecked by the single 1GB connection. Not ideal, but since you don't actually have a need for all ports to be used at once, you can get around it by making sure all the needy equipment shares the same switch, and relegate the low priority stuff like printers and such to the low priority switch. The good news is, if you wire all the jacks to the same closet, it's easy to patch what you need to whatever fits your purpose, and upgrading equipment shouldn't mean making sacrifices because of where you chose to terminate a specific wire. Also, good call having multiple drops to the TV areas, it's really cool to do a multiple source HDMI / USB / IR multiplexer back in the server closet, it means you can plop down a powerful gaming system to any given TV and have the VM or physical tower in the server closet. If that's the case, half your drops may end up on a HDBaseT matrix instead of connected to your switches.

With a router like that, I'd only have a single feed from the router to one of the non-POE switches, and set up the switches to talk directly to each other. Research the specific models you are using to find the best configuration for that, you may be able to team several ports between them, or depending on the model they will have ports specifically set up for that purpose (stackable). I am using a GS728TX, with 2 of the 4 10G ports connected to my 2 servers. Make sure all the media consumption outlets in use are on the same physical switch as your server(s), ideally your server would have a 10GB connection directly to one of the switches.

Actually we need the diagnostics zip file in its entirety, not just the syslog.

I would approach things a bit differently. Terminate all runs to a single location. The only exception to that would be if you have a house so freakin big that some of the runs would exceed 100 meters. If that's the case, this is the wrong place to discuss your network layout seriously, since you should have a network engineer on your payroll anyway. To determine which jack plugs in where, I'd try to determine traffic patterns, and keep all the significant bandwidth on a single switch. The goal being that as little as possible has to flow between switches. WAN traffic tends to be more limited than LAN traffic, so connect the router to the switch with the majority of the WAN traffic. Depends on your router and how powerful it is as to whether to daisy chain the switches or hub and spoke from the router. I'm assuming that you don't actually have 80+ wired network devices, and are simply ensuring that all jacks are live if needed. If that's the case, and you have 2 jacks per wallplate in many locations, then I'd make sure that the 2 jacks go to different switches so you have an easy troubleshooting step of changing jacks if needed. I'm also assuming the POE jacks are peppered about the house, so that switch needs runs all over anyway.

Parity can't help if any of the remaining drives have errors. All drives in the parity array must be fully trustworthy. I don't know of any plugins that do what your are asking, but a one line rsync command for each share in user scripts set to run periodically could do it. Honestly it sounds like you are headed for major data loss, unless the strategy changes drastically.

Indirectly, you do. massive bread errors in the syslog. I agree it would be nice if there was a notification event fired so you know about it immediately instead of seeing the chaos caused whenever you log in later. Maybe even an option to perform some action if /boot ceases to be populated. I'd like a configurable option to automatically shut down properly, even though it couldn't be recorded as a clean shutdown I'd know best efforts were taken to keep my data intact, and a notification that the boot USB was removed and the array shutdown properly would be good troubleshooting information when I bring the array back online. I just had a lightbulb moment. @Squid, would it be possible to mirror all writes to flash to a mounted image file on the array somewhere? A modified RAID1 of sorts? Then if the physical USB is unable to read or write, continue operating on the array copy, with the option to repair or remount the physical USB and bring it back in sync? I'm envisioning a system where flash replacement could be done live, with the license update happening on next array start.

Edit the first post and change the title.

The UPS that I use don't ever NOT use batteries. They are not switching, they are constant output totally isolated from the mains. Instead of monitoring the line power and reacting, the input is solely used to keep the batteries charged, and the output is constantly pulling from the batteries. They are rated for hospital equipment, which can and does include inductive loads.

Nope. Theoretically I suppose you could assign a 1GB USB thumb drive as disk1.

Did you disable the docker and VM services? As in, no Docker or VMS tab visible in the GUI?

Depends on the write mode selected in settings. Turbo (reconstruct) does exactly that, spins up all drives for writes.

It is important. I'm not saying that it isn't. It's just the urgent tag triggers a bunch of immediate attention, which isn't necessarily productive in this specific instance. Better to put it in the que of important things to try to fix, instead of in the "emergency we better find a solution before thousands of people corrupt their data" category, only to find out that it's not that big of a deal for 99% of the user base. Screaming for attention for something that in the grand scheme isn't a show stopper may cause the issue to get pushed down farther than it deserves to be as an over reaction to the initial panic. Politely asking for help resolving it goes a lot further than pushing the panic button.

With 1 parity disk assigned to parity1, and one data disk, yes, the operation is pretty much a RAID1. Any other configuration reverts to the general parity disk calculations, with the associated speed penalties. Disks can be configured to spin down when not being actively accessed. However, with only 2 disks and no cache drive defined, any docker container or VM services will keep the array spun up constantly.

Respectfully, while I agree that it's urgent in the sense that there is something wrong that needs to be addressed, there is a valid workaround in place to run unraid without triggering the issue, and it only effects a small subset of hardware. GUI mode just doesn't work properly on some systems. It's been that way since it's been introduced. I don't think this deserves the urgent tag, which implies a showstopper issue for general usage in a majority of hardware with no workaround.