VPS for internal company data storage, a 2026 setup guide

The first thing that breaks on a small company VPS is not the CPU. It is the disk filling up overnight because someone mounted a shared folder and dumped three years of photos into it. A VPS for internal company data storage is less about raw specs and more about access control, backup discipline, and choosing the right protocol for the job. This guide walks you through setting one up on Ubuntu 24.04 LTS, from picking the storage tool to automating nightly backups.

Prerequisites

• An Ubuntu 24.04 LTS VPS with at least 2 GB of RAM and 50 GB of NVMe disk. The Linux VPS plans with a dedicated IPv4 work well for this.
• A non-root user with sudo privileges. If you have not created one yet, do that first, then log in as that user for everything below.
• A static internal IP or a domain name pointing to the server, plus a firewall that allows only your office or VPN subnet.
• Basic familiarity with SSH, systemd, and the command line. You will be editing config files and reading logs.

Why a VPS beats a NAS or a cloud drive for internal data

Most teams default to Google Drive or a consumer NAS. Both work until you need to control who can read a specific folder, or until you need to comply with local data residency rules. A VPS for internal company data storage gives you full root access, which means you decide where the data lives, who touches it, and how it is backed up. That is the real value, not the hardware.

For a company operating in Vietnam, keeping data on a rent Linux VPS inside the country also removes the latency and compliance questions that come with offshore storage. The trade-off is that you become the admin. No one will hold your hand when a disk fills up at 2 a.m., so you need to build the safety nets before you need them.

Step 1 - Pick the right storage protocol: Samba or Nextcloud

There are two sane options for a small team. Samba gives you native file shares that mount like local drives in Windows, macOS, and Linux. Nextcloud gives you a web interface, sync clients, and versioning, at the cost of more moving parts.

For a VPS for internal company data storage that mostly serves office documents, Samba is the better default. It is one service, one port, and no database to maintain. If you need web access or file versioning, run Nextcloud in Docker with a PostgreSQL backend. Both are covered below.

Step 2 - Set up Samba on Ubuntu 24.04 for a shared drive

Install Samba and create a directory structure that separates departments or projects.

sudo apt update
sudo apt install -y samba
sudo mkdir -p /srv/share/finance /srv/share/engineering /srv/share/general
sudo chown -R root:sambashare /srv/share
sudo chmod -R 2770 /srv/share

The stick bit on the group permission, the 2 in 2770, ensures files created inside stay in the sambashare group. Now create a system user for each team member and add them to the sambashare group.

sudo useradd -M -s /usr/sbin/nologin anna
sudo smbpasswd -a anna
sudo usermod -aG sambashare anna

Edit /etc/samba/smb.conf and append a share definition. Keep it minimal, no guest access.

[general]
path = /srv/share/general
valid users = @sambashare
read only = no
create mask = 0660
directory mask = 2770
browseable = yes

Reload Samba and check that the share is visible.

sudo systemctl restart smbd
sudo smbclient -L localhost -U anna

You should see the general share listed after authenticating. Mount it on a test workstation with mount -t cifs //server/general /mnt/share -o username=anna and write a file to confirm the permissions work end to end.

Step 3 - A Nextcloud alternative when you need web access

If your team works remotely or needs to share large files over a link, Nextcloud is the stronger choice. The cleanest install path on a VPS is Docker Compose. Create a directory and a compose file.

mkdir -p /opt/nextcloud && cd /opt/nextcloud
nano docker-compose.yml

Use the official image with a PostgreSQL container. The version: key is deprecated in current Compose, so leave it out.

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: change_this_db_password
    volumes:
      - db_data:/var/lib/postgresql/data
  app:
    image: nextcloud:stable
    ports:
      - "8080:80"
    volumes:
      - nextcloud_data:/var/www/html
    depends_on:
      - db
volumes:
  db_data:
  nextcloud_data:

Start the stack and verify it responds.

sudo docker compose up -d
curl -I http://localhost:8080

You should get a 200 or 302 response. Finish the setup in the browser, then harden it by placing it behind an Nginx reverse proxy with HTTPS. A wildcard SSL certificate keeps subdomains easy later.

Step 4 - Lock down access to the storage VPS

A storage server that is reachable from anywhere on the internet is a liability. Restrict access to your office IP or a VPN. nftables is the default firewall backend on Ubuntu 24.04, so use nft for the ruleset. Allow SSH and the SMB port 445 from your office subnet only, and drop the rest.

sudo nano /etc/nftables.conf

Place this ruleset in the file, replacing 203.0.113.0/24 with your real office or VPN range.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop
    ct state established,related accept
    iif lo accept
    ip saddr 203.0.113.0/24 tcp dport { 22, 445 } accept
    ip saddr 203.0.113.0/24 tcp dport 443 accept
  }
  chain forward { type filter hook forward priority filter; policy drop }
}

table inet nat {}

Load it and confirm the ruleset is active. Do not close your SSH session until you have verified you can still connect.

sudo nft -f /etc/nftables.conf
sudo systemctl enable nftables
sudo nft list ruleset

For remote users, run a WireGuard VPN instead of exposing SMB directly. SMB over the public internet is a bad idea even with a strong password, the protocol is too old and too exposed.

Step 5 - Automate offsite backups with restic

Storage without backups is not storage, it is a countdown. Restic gives you encrypted, deduplicated backups to any object storage or remote server. Install it and point it at a repository on a separate machine.

sudo apt install -y restic
restic init --repo sftp:[email protected]:/srv/backups/company-data

Create a script at /usr/local/bin/backup-data.sh that snaps the shares and prunes old snapshots by policy.

#!/bin/bash
export RESTIC_PASSWORD="a_long_random_passphrase"
export RESTIC_REPOSITORY="sftp:[email protected]:/srv/backups/company-data"
restic backup /srv/share
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Make it executable and schedule it with a systemd timer, which is cleaner than cron for this job.

sudo chmod +x /usr/local/bin/backup-data.sh
sudo nano /etc/systemd/system/backup-data.service
sudo nano /etc/systemd/system/backup-data.timer

The service file runs the script, the timer fires it nightly at 2 a.m.

[Unit]
Description=Nightly backup of company data

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-data.sh

Enable the timer and verify it is scheduled.

sudo systemctl daemon-reload
sudo systemctl enable --now backup-data.timer
systemctl list-timers backup-data.timer

Test a restore at least once. A backup you have never restored is a rumor.

Troubleshooting common storage VPS failures

Disk fills up silently. This is the most common failure. Set up a cron job or a monitoring check that alerts you at 80 percent usage, and add a logrotate rule for anything that writes logs into the share.

Samba is slow over the internet. That is expected, SMB is chatty. Run Samba over WireGuard or stick to Nextcloud for remote clients. Do not tune Samba for WAN links, it will not help.

Users cannot write even though permissions look right. Check the mount options on the client and the group of the directory on the server. The 2770 mask covers new files, but an existing directory with the wrong group breaks everything. Run sudo ls -la /srv/share to inspect the real owner and group.

Monitoring disk usage and user quotas

Quotas prevent one person from filling the disk. Enable them on the filesystem, then set soft and hard limits per user.

sudo apt install -y quota
sudo nano /etc/fstab

Add ,usrjquota=aquota.user,jqfmt=vfsv1 to the options of the partition that hosts /srv/share, then remount and build the quota files.

sudo mount -o remount /srv/share
sudo quotacheck -cum /srv/share
sudo quotaon /srv/share
sudo setquota -u anna 5G 6G /srv/share

Anna now gets a 5 GB soft limit and a 6 GB hard limit. When she hits the soft limit she has a grace period to clean up, past the hard limit writes fail cleanly and the server keeps running. Track usage with sudo repquota -a and feed that into your monitoring dashboard if you already run Prometheus and Grafana on another VPS.

What specs does a storage VPS actually need

Storage workloads are not CPU hungry. A 2 GB RAM VPS with 2 vCPUs is enough for a team of ten using Samba. Add a GB of RAM if you run Nextcloud with PostgreSQL, the database and PHP cache eat memory fast. Disk space is the variable that matters, buy as much as the plan allows and keep the OS on a separate volume if the provider supports it.

For a growing team, a 4GB RAM VPS gives comfortable headroom for Nextcloud plus its cron jobs, and for a 8GB RAM VPS you can add full-text search without feeling the squeeze. Whatever you pick, monitor disk usage weekly and do a monthly restore drill. The cheapest storage plan is the one that fails a restore test, everything else is priced wrong.

FAQ

Related articles

• How to back up a VPS before an upgrade
• How to benchmark NVMe disk speed on a VPS
• Set up nftables firewall on a VPS to replace iptables
• Self-host VPS monitoring with Prometheus and Grafana