Setting up a Synology server, I made the mistake of just buying a UPS that had a USB plug on the back thinking oh this is a solved problem, it must just work. No no far from it.
So the UPS I mistakenly purchased is not compatible with Synology. SRV1KI-E wants to run this weird program called PowerChute.
Anyone have success marrying this into the Synology ecosystem?
It also has a RS 232 serial port, I wonder if there’s an off-the-shelf device that would speak serial but output power state via the network or USB.
Right now when updates get applied to the NAS, if it gets powered off during the update window that would be really bad and inconvenient require manual intervention.
In memory caching, and the Amy cashing, well I think the file system would almost certainly be in a consistent state, you might lose data in flight if you’re not careful.
The real problem, that I need an nas for, is not the loss of some data, it’s when the storms hit and there’s flooding, the power can go up and down and cycle quite rapidly. And that’s really bad for sensitive hardware like hard disks. So I want the NAS to shut off when the power starts getting bad, and not turn on for a really long time but still turn on automatically when things stabilize
Because this device runs a bunch of VMs and containers as well closing down so that all of those rights get flushed is good practice
Right now when updates get applied to the NAS, if it gets powered off during the update window that would be really bad and inconvenient require manual intervention.
You sure? I mean, sure, it’s possible; there are devices out there that can’t deal with power loss during update. But others can: they’ll typically have space for two firmware versions, write out the new version into the inactive slot, and only when the new version is committed to persistent storage, atomically activate it.
Last device I worked on functioned that way.
you might lose data in flight if you’re not careful.
That’s the responsibility of the application if they rely on the data to be persistent at some point; they need to be written to deal with the fact that there may be in-flight data that doesn’t make it to the disk if they intend to take other actions that depend on that fact; they’ll need to call fsync() or whatever their OS has if they expect the data to be on-drive.
Normally, there will always a period where some data being written out is partial: the write() could complete after handing the data off to the OS’s buffer cache. The local drive could complete because data’s in its cache. The app could perform multiple write() calls, and the first could have completed without the second. With a NAS, the window might be a little bit longer than it otherwise would be, but something like a DBMS will do the fsync(); at any point, it’d be hypothetically possible for the OS to crash or power loss or something to happen.
The real problem, that I need an nas for, is not the loss of some data, it’s when the storms hit and there’s flooding, the power can go up and down and cycle quite rapidly. And that’s really bad for sensitive hardware like hard disks. So I want the NAS to shut off when the power starts getting bad, and not turn on for a really long time but still turn on automatically when things stabilize
Like I said in the above comment, you’ll get that even without a clean shutdown; you’ll actually get a bit more time if you don’t do a clean shutdown.
Because this device runs a bunch of VMs and containers
Ah, okay, it’s not just a file server? Fair enough – then that brings the case #2 back up again, which I didn’t expect to apply to the NAS itself.
I was surprised too. But a lot of the current NAS devices basically operate as hosting devices. It makes sense the hard drives are there the power is there the RAM is there the CPU is there. So for the low intensity containers and VMs you want to run like a Plex server, or DNS server, or tail scale it’s all right there
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
Right now when updates get applied to the NAS, if it gets powered off during the update window that would be really bad and inconvenient require manual intervention.
In memory caching, and the Amy cashing, well I think the file system would almost certainly be in a consistent state, you might lose data in flight if you’re not careful.
The real problem, that I need an nas for, is not the loss of some data, it’s when the storms hit and there’s flooding, the power can go up and down and cycle quite rapidly. And that’s really bad for sensitive hardware like hard disks. So I want the NAS to shut off when the power starts getting bad, and not turn on for a really long time but still turn on automatically when things stabilize
Because this device runs a bunch of VMs and containers as well closing down so that all of those rights get flushed is good practice
You sure? I mean, sure, it’s possible; there are devices out there that can’t deal with power loss during update. But others can: they’ll typically have space for two firmware versions, write out the new version into the inactive slot, and only when the new version is committed to persistent storage, atomically activate it.
Last device I worked on functioned that way.
That’s the responsibility of the application if they rely on the data to be persistent at some point; they need to be written to deal with the fact that there may be in-flight data that doesn’t make it to the disk if they intend to take other actions that depend on that fact; they’ll need to call
fsync()or whatever their OS has if they expect the data to be on-drive.Normally, there will always a period where some data being written out is partial: the
write()could complete after handing the data off to the OS’s buffer cache. The local drive could complete because data’s in its cache. The app could perform multiplewrite()calls, and the first could have completed without the second. With a NAS, the window might be a little bit longer than it otherwise would be, but something like a DBMS will do thefsync(); at any point, it’d be hypothetically possible for the OS to crash or power loss or something to happen.Like I said in the above comment, you’ll get that even without a clean shutdown; you’ll actually get a bit more time if you don’t do a clean shutdown.
Ah, okay, it’s not just a file server? Fair enough – then that brings the case #2 back up again, which I didn’t expect to apply to the NAS itself.
I was surprised too. But a lot of the current NAS devices basically operate as hosting devices. It makes sense the hard drives are there the power is there the RAM is there the CPU is there. So for the low intensity containers and VMs you want to run like a Plex server, or DNS server, or tail scale it’s all right there