Sharing between 2 servers for storage.

I am quickly running out of space due to new signups I host with hostinger where the price is great, I have a KVM 8 server with them with 400gb of space,the biggest they do and none expandable on disk space. I keep reading a lot on here especially @Romulus posts and questions, Now I do not have much time left to make decissions I would like to stay with hostinger self hosted KVM8 as the price is great, I have a few KVM 8 servers with them one of them is empty , How can I use this for storage to daisy chain them just for hard drive usage purpose. Also I want to limit down time on the server while I do this .

I look forward to any response and guidance and thank you I appreciate your knowledge

Simon

  • 128
  • 2
Comments
      • Also a simple setup for Permanent NFS Setup for UNA APP on Debian

        NFS Server Setup

        1. Install NFS server:
        sudo apt update sudo apt install -y nfs-kernel-server 
        
        1. Create shared storage folder:
        sudo mkdir -p /mnt/storage sudo chown -R nobody:nogroup /mnt/storage sudo chmod 775 /mnt/storage 
        
        1. Configure exports:

        Edit /etc/exports:

        /mnt/storage 10.0.0.0/24(rw,sync,no_subtree_check,all_squash,anonuid=33,anongid=33)
        
        • 10.0.0.0/24 → your private network
        • all_squash, anonuid=33, anongid=33 → maps all files to www-data (uid 33) for proper UNA APP permissions
        1. Export the folder and start NFS:
        sudo exportfs -a sudo systemctl enable nfs-server sudo systemctl restart nfs-server 
        
        1. Optional firewall:
        sudo ufw allow from 10.0.0.0/24 to any port nfs 
        

        NFS Client Setup (UNA APP Server)

        1. Install NFS client:
        sudo apt update sudo apt install -y nfs-common 
        
        1. Create mount point for UNA APP:
        sudo mkdir -p /var/www/una/storage sudo chown www-data:www-data /var/www/una/storage sudo chmod 775 /var/www/una/storage 
        
        1. Test manual mount:
        sudo mount -t nfs <NFS_SERVER_IP>:/mnt/storage /var/www/una/storage 
        

        Check:

        df -h | grep storage 
        

        Make NFS Mount Permanent

        1. Edit /etc/fstab:
        <NFS_SERVER_IP>:/mnt/storage /var/www/una/storage nfs defaults,_netdev,auto 0 0
        
        • _netdev → ensures mount waits for network
        • auto → mounts automatically on boot
        1. Test fstab:
        sudo mount -a 
        

        No errors → mount will survive reboots.

        Summary

        • NFS storage mounted permanently at /var/www/una/storage
        • Fully compatible with UNA APP
        • Permissions mapped to www-data
        • No other services included – simple, scalable, and persistent


        💡 Recommendations for NFS Setup

        1. Use a dedicated disk
        • Always allocate a separate, empty disk for NFS storage.
        • Avoid using the same disk as the operating system.
        • This prevents I/O bottlenecks and ensures better performance.
        1. Keep workloads separate
        • Do not mount NFS on the OS disk.
        • Mixing operating system and storage workloads will slow down the entire system.
        1. Configure file descriptor limits
        • NFS and applications like UNA may open thousands of files simultaneously.
        • Increase nofile limits to avoid errors such as “Too many open files”.
        1. Use a private network
        • Isolate NFS traffic from public traffic (VLAN, VPN, or dedicated NIC).
        • This prevents slowdowns for your users and improves security.
        1. Plan for scalability
        • NFS is suitable for temporary or small-scale setups.
        • For long-term growth and higher performance, migrate to OpenStack Cinder or another distributed storage backend.

        ⚠️ Note:

        NFS is a simple and functional solution for temporary storage or basic setups. However, it does not scale well with multiple volumes or high traffic. If you want a cloud-ready setup, NFS can be a starting point, but the recommended long-term approach is OpenStack with a dedicated storage backend for performance and scalability.

        👉 In short: dedicate hardware for NFS, configure limits, isolate storage traffic, and use NFS as a stepping stone toward a scalable cloud infrastructure.

        ⚠️ IMPORTANT NOTICE

        • 🚨 These commands and configuration changes are for informational purposes or development.
        • 💾 They DO NOT represent an official setup guide.
        • ⚙️ Run them ONLY if you fully understand what they do.
        • ❗ Use at your own risk. Adjust if necessary.
        • 👉 This example is intended for advanced users only.

        ✨ Happy coding!

        • Absolutely amazing, What a great asset to una @Romulus

          • ⚠️ Disclaimer

            • Dedicated disk: Always use a separate, empty disk for NFS storage. Avoid using the same disk as the operating system to prevent I/O bottlenecks and ensure better performance.
            • No mixing workloads: Do not mount NFS on the OS disk. Mixing OS and NFS workloads will slow down the entire system.
            • File descriptor limits: NFS and applications like UNA may open thousands of files simultaneously. Increase nofile limits to avoid errors such as “Too many open files”.
            • Private network: Use a private network (VLAN, VPN, or dedicated interface) for NFS traffic. This prevents slowdowns for your users and improves security.
            • Scalability: NFS is fine as a temporary or simple solution. For long-term growth and high performance, migrate to OpenStack Cinder or another distributed storage backend.
            • If you choose the simple NFS solution, read the recommendations carefully.
            • I do not know what operating system or exact server configuration you are using, so I cannot provide a one-size-fits-all recipe. The commands shown are only examples and must be adapted to your environment.
            • The NFS server should be a freshly installed system, dedicated exclusively to NFS, with a separate disk (not the OS disk), and no other services running.
            • If you only have one disk on the vps, you must first create a separate partition before configuring it for NFS.

            On a VPS, the open files limit (nofile) can be set by the provider, and in many cases, it cannot be fully modified by a normal user or even by root.

            Some details:

            1. VPS-imposed limits:
            • Some VPSs (especially shared or container-based ones, like OpenVZ) have strict limits on open files.
            • These limits are set in the kernel or via cgroups and cannot be bypassed without provider intervention.
            1. Check current limits:
            ulimit -n cat /proc/$(pidof )/limits 
            
            1. Attempting to modify:
            • You can try changing /etc/security/limits.conf or /etc/systemd/system.conf / /etc/systemd/user.conf, but on a VPS these changes may be ignored if the provider enforces restrictions.
            • Example /etc/security/limits.conf:
            *    hard    nofile    65535
            *    soft    nofile    65535
            
            1. What you can do:
            • Check with your provider if the VPS supports increasing the open files limit.
            • If not, for applications requiring many simultaneous open files (like NFS + UNA), it’s safer to use a dedicated server or a VPS with full control (KVM, Proxmox, etc.), where you can set limits as needed.

            If you use a VPS and the nofile limit is too low, you won’t be able to run NFS + UNA at full capacity without restrictions. A dedicated server or fully controllable VPS is recommended.

            For optimal performance and reliability, a dedicated server with two disks in RAID for the operating system and two separate disks in RAID for NFS storage is recommended. You need to be aware that on a VPS even KVM-based, you have limited control and can’t do too much. Also, make sure to read your provider’s terms and conditions: modifying limits could be considered a violation of their usage policies, and your contract could be terminated. Therefore, always request permission from your provider first.

            DOCS:

          • I really appreciate your help. With kindest appreciation Simon. I will study and come back to you Thanks

            • Simon, honestly, instead of paying for multiple KVM servers and creating extra points of failure, you’d be better off with a dedicated server at Hetzner.

              Comparison:

              2x Hostinger KVM 8 – €19.99/month (renews at €49.99/month)

              • 8 vCPU
              • 32 GB RAM
              • 400 GB NVMe SSD
              • 32 TB bandwidth

              Hetzner Auction Dedicated (Budget option) – €41.29/month

              • Intel Core i7-8700
              • 2 × 1TB NVMe SSD
              • 128 GB DDR4 RAM (4 × 32 GB)
              • 1 Gbit Intel NIC unlimited bandwidth

              Hetzner Auction Dedicated (Performance / Long-term option) – ~ €103.17/month

              • Intel Core i9-9900K
              • 2 × 1TB NVMe SSD
              • 2 × 3.84TB SATA Datacenter SSDs (huge extra storage)
              • 128 GB DDR4 RAM (4 × 32 GB)
              • 1 Gbit Intel NIC unlimited bandwidth

              👉 For nearly the same price as two KVM 8s, the i7 option gives you far more RAM and storage, with no need to daisy-chain servers.

              👉 And if you want something more powerful and future-proof, the i9 option with nearly 9 TB of total SSD storage is still very reasonable at ~€103/month.

              I also recommend enabling Hetzner’s backup service then you’ll be fully covered.

              Hetzner also provides an S3-compatible storage API you can use as a CDN. You can even create internal private networks between servers to scale later.

              Honestly, I don’t see any reason to stay stuck with VPS when you’re past the beginner stage. VPS is fine for tuild cheap private cloud , or testing apps, but not for production. Spending time trying to daisy chain VPS instances for storage is, in my opinion, a mistake.

              You can read all the documentation you want, but without real power your site will stay in the same place. If you want to grow profesional website, go to dedicated servers, an then plan ahead and build a private cloud, and you’ll be in a much stronger position. If you don't like Hetzner, there are other providers.

              Without investment you can't have expectations. From my point of view, this topic is closed. Good luck

              Login or Join to comment.