It would be amazing if PCIe lanes becomes the predominant limiting factor, rather than drive cost, for building large storage arrays. What a world it would be, when even Epyc and its lanes-for-days proves to be insufficient for large Chia miners err Plex servers uh, Linux ISO mirrors.

I’m afraid I have no suggestions for DoT servers.

One tip for your debugging that might be useful is to use dig to directly query DNS servers, to help identify where a DNS issue may lay. For example, your earlier test on mobile happened to be using Google’s DNS server on legacy IP (8.8.8.8). If you ran the following on your desktop, I would imagine that you would see the AAAA record:

dig @8.8.8.8 mydomain.example.com

If this succeeds, you know that Google’s DNS server is a viable choice for resolving your AAAA record. You can then test your local network’s DNS server, to see if it’ll provide the AAAA record. And then you can test your local machine’s DNS server (eg systemd-resolved). Somewhere, something is not returning your AAAA record, and you can slowly smoke it out. Good luck!

If I understand correctly, you’re now able to verify the AAAA on mobile. But you’re still not able to connect to the web server from your mobile phone. Do I have that right?

I believe in a different comment here, you said that your mobile network doesn’t support IPv6, and nor does a local WiFi network. In that case, it seems like your phone is performing DNS lookups just fine, but has no way to connect to an IPv6 destination.

If your desktop does have IPv6 connectivity but has DNS resolution issues, then I would now look into resolving that. To be clear, was your desktop a Linux/Unix system?

If you describe what you configured using DNS and what tests you’ve performed, people in this community could also help debug that issue as well.

An AAAA records to map a hostname to an IPv6 address should be fairly trouble-free. If you create a new record, the “dig” command should be able to query it immediately, as the DNS servers will go through to the authoritative server, which has the new record. But if you modified an existing record, then the old record’s TTL value might cause the old value to remain in DNS caches for a while.

When in doubt, you can also aim “dig” at the authoritative name server directly, to rule out an issue with your local DNS server or with your ISP’s DNS server.

Could you let us know what the DNS issue was?

I recall watching a documentary (on Curiosity Stream maybe? I’m no longer subscribed) on data storage longevity. It covered DNA storage, which I think this PBS video w/ transcript provides more recent coverage of its developments. As well as holographic storage, which I could only find the Wikipedia page for.

As for which one I think might be the future, it’s tough to say. Tape is pretty good and cheap but slow for offline storage. Archival media will probably end up all being offline storage, although I could see a case for holographic/optical storage being near line. Future online storage will probably remain a tough pickle: cheap, plentiful, fast; select at most two, maybe.

If the server is sent a signal to shutdown due to a grid outage, who is telling it the grid was restored?

Ah, I see I forgot to explain a crucial step. When the UPS detects that grid power is lost, it sends a notification to the OS. In your case, it is received by apcupsd. What happens now is a two step process: 1) the UPS is instructed to power down after a fixed time period – one longer than it would take for the OS to shut down, and 2) the OS is instructed to shut down. Here is one example of how someone has configured their machine like this. The UPS will stay off until grid power is restored.

In this way, the server will indeed lose power, shortly after the OS has already shut down. You should be able to configure the relevant delay parameters in apcupsd to preserve however much battery state you need to survive multiple grid events.

The reason the UPS is configured with a fixed time limit – as opposed to, say, waiting until power draw drops below some number of watts – is that it’s easy and cheap to implement, and it’s deterministic. Think about what would happen if an NFS mount or something got stuck during shutdown, thereby running down the battery, ending up with the very unexpected power loss the UPS was meant to avoid. Maybe all the local filesystems were properly unmounted in time, but when booting up later and mounting the filesystems, a second grid fault and a depleted battery state could result in data loss. Here, the risk of accidentally cutting off the shutdown procedure is balanced with the risk of another fault on power up.

Answering the question directly, your intuition is right that you’ll want to limit the ways that your machine can be exploited. Since this is a Dell machine, I would think iDRAC is well suited to be the control mechanism here. iDRAC can accept SNMP commands and some newer versions can receive REST API calls.

But stepping back for a moment, is there any reason why you cannot configure the “AC Power Recovery” option in the system setup to boot the machine when power is restored? The default behavior is to remain as it was but you can configure it to always boot up.

From your description, it sounds like your APC unit notifies the server that the grid is down, which results in the OS shutting down. Ostensibly, the APC unit will soon diminish its battery supply and then the r320 will be without AC power. When the grid comes back up, the r320 will receive AC power and can then react by booting up, if so configured. Is this not feasible?

The end of the cable attaching to each drive needs to receive a SATA power cable, just like a standard SATA drive would need.

The first link is an SFF-8087 to 4x SFF-8482. While this cable could technically support SAS3 speeds, the SFF-8087 connector was specified for SAS2, not SAS3. As a result, you won’t really find any HBAs that have an SFF-8087 connector and do SAS3 over it. This cable is incompatible with the 9300-8i from your second link. I would choose something more like this: https://www.amazon.com/dp/B01GPD5KFK . Also be advised that if your SSD isn’t recognized with this cable, the reviews mention that the 3.3v power pin – if you have one at all – might need to be disabled, to avoid PWDIS issues.

For the second link, that Inspur 9300-8i appears identical to the HBA I have, and it’s worked fine for me, although I only have SAS2 drives hooked up to it right now. The nice thing is that the listing advertises “IT mode”, which was important to me, because burning firmware to switch to IT mode is a sad experience.

EDIT: BTW, when you receive this drive, you should probably dump the SMART data to see how much lifetime is left on this SSD. This is an enterprise SSD, so it’s possible that it came from several years of use as a caching drive in a server somewhere. That could do a number to its remaining lifetime, but I would imagine its performance would fit well for your use-case.

I’m afraid I don’t have much experience with benchmarking in Windows. I think I’ve seen CrystalDiskMark mentioned in a few places, and it’s FOSS under MIT License.

BTW OP: when you get this set up, please run some benchmarks and tell this community how it performs. I’ve had a free PM1633A sitting on my desk for 1.5 years, just because I haven’t gotten around to it. I’m keen to know how it behaves.

An aside: one-to-many breakout cables have a forward and backward variety, and care must be taken to avoid buying the wrong one. This link explains the difference, which is still applicable to SAS3: https://forums.unraid.net/topic/6723-sas-to-sata-cables-forward-or-reverse-which-where-why/

Note that some combinations of backwards breakout cables simply don’t exist, so there might be only one version available for sale. Still, read the product descriptions carefully for which end is meant for the HBA and which end goes to drives or the backplane.

To summarize a few details, the PM1633A is a SAS3 (aka SAS 12 Gbps) SSD drive, which accepts an SFF-8482 plug. This SFF-8482 plug is the one named in the SAS3 standard for use on drives. You mention the LSI 9311 HBA, which does support SAS3 and has a pair of SFF-8643 receptacles, which is specified in the SAS3 standard for use on backplane aggregators. That is to say, when multiple drives are bundled up onto a single cable.

When used for SAS3, SFF-8643 supports up to four drives. And so you will find forward-breakout cables online that go from SFF-8643 to 4x SFF-8482.

The cable you mentioned – an SFF-8643 to SFF-8639 – is meant for U.2 drives. Because of the 4x PCIe lanes used for U.2, a single drive uses all the pins in an SFF-8643 plug, which is why this cable can only attach to a single drive. Because SFF-8639 is backwards compatible with SFF-8482, this could still be used for SAS3 drives, but it would waste the other three “lanes” in the cable.

With all that said, I would not recommend the cable you listed, and instead replace it with the aforementioned forward-breakout to 4x SFF-8482. This way, you can later buy three more SAS3 drives. I presume you’re not planning to ever use U.2 here.

Also, regarding the choice of HBA, was there a reason you chose the 9311? I have both the venerable 9300-8i and a newer 9305-16i. Both work great for me and support SAS3. It’s notable that power and heat is lower on the 9305. The 9300, 9305, and 9311 all have the same pair of SFF-8643 connectors.