NAS

I feel like I'm missing something important in your comment. The reason for shutting down the app is to make sure everything is in a good state including databases and so forth. Snapshotting can lead to corruption if the app is running.

Why not have the option for the app to simply shut down then snapshot and restart?

I want you to know I successfully migrated only to experience database corruption about a week later losing my instance. I have a backup of the raw data fortunately. I understand engineering resources but this is why we really need to be able to have arbitrary backup and restore per app. Please bring that engineering focus to implement backup and restore up sooner than later. I can't wait to see that functioning built into buddy back up as well! More thoughts it looks like there's others in the community that are looking forward to this future as well see TrueNas Scale needs a first party application backup and restore system

I agree I had a boot drive go down and there's no way to get back my apps without significant effort and risk of data loss.

With Back Up Buddy, will I be able to backup applications and vm's so I can restore them anywhere? I'm very hesitant to start hosting applications until there's a way that I can ensure the app data is safely backed up and restoreable. The hope for this feature is essentially what brought me to HexOS.

Buddy backups looks like it'll cloud only. I hope this is just for coordination once configured the cloud shouldn't be involved.

It would be nice to to speed test to accurately measure: Network Throughput to the NAS: This tests the raw network connection speed, isolating it from storage performance. We need a reliable way to determine if our network infrastructure is delivering the expected bandwidth. Storage Pool Performance: Benchmarking the combined performance of a pool is crucial including sequential and random read/write operations. Individual Drive Performance: Testing individual HDDs, SSDs, or NVMe drives. This is vital for diagnosing drive health and identifying potential bottlenecks

I'm also interested in experience utilizing Intel N100 based NAS. My use case is for backup purposes with a similar raidz2 configuration. Let us all know how it goes!

Unless there is a past history of abuse why can't we simply edit a post at any time. I ran into this again today and it's really frustrating.

If I were to sum it up HexOS should operate under the principle that applications are not not be trustworthy and build out their infrastructure accordingly.

HexOS needs to establish a threat model with their curated applications and communicate that to the community. What kind of threats could we face based on how an application is being used and exposed to the network? Use Case 1: Exposing an Application to the WAN (Public Access) Threats: External Attackers: Malicious actors may exploit vulnerabilities in the application, potentially allowing unauthorized access. DDoS Attacks: Distributed Denial of Service attacks could overwhelm the application and its associated infrastructure. Man-in-the-Middle (MitM) Attacks: Attackers could intercept communications between users and the application. Misconfigured Security Measures: Vulnerabilities arising from misconfigured HexOS firewall rules or other security protocols could expose internal services. Use Case 2: Exposing Services Through LAN Only Threats: Internal Threats: Malicious users or compromised devices within the LAN pose risks to security. Exploitable Configurations: Poor application setups or vulnerabilities could be exploited by other trusted users or devices. Lateral Movement Risks: A compromised endpoint within the LAN could facilitate lateral movement to access other internal services. Challenges in Mitigation Some threats are difficult to mitigate effectively: DDoS Attacks: When executed well, these attacks are challenging to block and often require upstream infrastructure beyond HexOS to manage effectively. Firewall Configuration: While HexOS firewalls can be configured to improve security, managing upstream infrastructure, such as routers or dedicated firewalls, falls outside the scope of HexOS documentation. My Recommendations Users may need to expose certain applications only through the WAN (for external VPN access or public access) while limiting others to the LAN. It is crucial to recognize that the LAN should not be treated as a trusted network, as other services can be compromised, serving as a foothold for further intrusions. The following recommendations can help enhance security, depending on backend implementations designed to protect users: Application Isolation Deploy applications in separate virtual or physical environments (e.g., using containers or separate Virtual Private Clouds). Restrict outbound and inbound traffic to only the necessary connections for application functionality, applying the principle of least privilege. Access Control Implement strong authentication and authorization mechanisms (e.g., OAuth, API keys) to ensure that only legitimate users can access the system. Traffic Encryption Utilize HTTPS to encrypt data in transit, safeguarding against MitM attacks. Implement VPN gateways that can securely manage encrypted traffic for sensitive operations. Many of these thoughts mention here come from seeing some open source projects like casaos and cosmos-server that have mitigated some of these security threats. I'm sure Hex OS can provide even better experience if they lay the proper groundwork now. That ground work starts with the egress and structuring templates for applications.

I wouldn't mind throwing my hat into the beta test.

Clarification to the post above: restore in reverse chronological order one at a time. If that's true can we expect a average hexos to follow that practice? sigh fyi... the edit timeout needs to be removed from the forums.

I reached out to another forum for clarification about ZSF. So I understand now that a rollback is a rollback and not a restore. A rollback mounts that read-only snapshot allowing recovery of files. I believe my initial concern is still valid. A rollback is only helpful if the user knows explicitly what needs to be restored.even (if it is exposed by a file system) Two have (users A and B) 4000 in photos Immich User B has been tagging a thousand photos over the course of a weeks The application crashes and is unrecoverable. This goes unnoticed for two weeks. How does the A user know when to restore when there are many bad snapshots of application not working? Assume they don’t have a deep knowledge of application (looking at logs, most people don’t). It seems to me the user would have to use trial and error to with multiple restores of the application to discover it's working snapshot. However this comes at a great risk of losing data. In this case rollback isn’t helpful because the corrupt data isn’t obvious to the user. They don’t know if it application can run just by looking at files nor can they know how much of losing the metadata because it stored in a database. The only thing I can think of the user will have to restore incrementally in chronological order to ensure they get the latest working snapshot for the application without data a loss.

As I understand random nature of errors occurring with any type of RAM that ECC RAM mitigates. However it does ECC RAM maintain data integrity when the ECC RAM starts to go bad?