Onboard Server, NAS, and Backup Roles Explained

This article applies to yachts using onboard servers, NAS units, virtual machine hosts, media libraries, monitoring servers, backup appliances, cloud backup, local file shares, CCTV storage, owner-office file storage, or technical documentation repositories.

Applicability depends on yacht size, network architecture, owner-office requirements, AV/media design, CCTV retention, management-company systems, privacy obligations, refit history, cloud access, and whether onboard storage supports bridge-adjacent, security, engineering, or OT data.

The key question is not "what storage do we have?" The key question is "what role does each system perform, and who can restore it when it fails?"

Many yachts accumulate storage over time. A NAS may start as a simple file share, then become backup storage, media storage, camera archive, VM datastore, and technical handover folder. A server may host monitoring tools, vendor software, media services, password vault exports, and old project files. A cloud drive may hold critical documents without anyone onboard knowing who controls the account.

The result is a system that appears useful until it fails.

When a NAS goes offline, the question should not be "who installed this?" It should be:

• What service has stopped?
• What data is stored there?
• Is it the original data, a backup, or both?
• Who owns the restore decision?
• Where is the last verified backup?
• What happens if the internet is unavailable?

If those answers are unclear, the yacht has a storage governance problem, not only a hardware problem.

Start by naming the role of each storage or server system. One physical box can have more than one role, but the roles should still be documented separately.

Common roles include:

• file server,
• NAS storage,
• backup repository,
• media library,
• CCTV or NVR storage,
• virtual machine host,
• monitoring server,
• software licence server,
• owner-office document store,
• technical documentation archive,
• local cache for cloud services.

Avoid vague labels such as "main server" or "technical NAS." Those names do not tell the next engineer what is at risk.

File services are usually where yacht teams store documents, handover files, technical records, guest operations files, maintenance reports, purchase records, drawings, and shared departmental folders.

For each file service, record:

• owner,
• users and groups,
• sensitive folders,
• access method,
• offline access behaviour,
• cloud sync relationship,
• backup target,
• restore process.

Permissions matter. A share that contains network diagrams, payroll files, guest details, procurement records, or owner office files should not be open to every crew device.

Also check whether local folders are being synced to cloud platforms. A file may appear "on the NAS" while the real collaboration copy lives in Microsoft 365, Google Workspace, Dropbox, or another platform.

NAS units are common onboard because they are compact, familiar, and easy to expand. Synology, QNAP, TrueNAS, and similar platforms can be useful when managed properly.

The risk is that a NAS can become too many things at once.

A NAS might store files, run apps, host backups, present iSCSI storage, replicate to cloud, serve media, hold CCTV exports, and provide snapshots. That flexibility is useful, but each role needs a restore plan.

Document:

• storage pool and RAID state,
• snapshot schedule,
• user and group permissions,
• admin accounts,
• update policy,
• backup jobs,
• replication jobs,
• cloud sync jobs,
• UPS connection,
• alert email or monitoring destination,
• spare drive model and location.

RAID is not a backup. Snapshots are not always a backup. Cloud sync is not always a backup. A good article, handover, or survey pack should make that distinction clear.

Some yachts run local virtualisation for monitoring tools, vendor software, Windows services, media management, logging, or small application servers.

VM hosts may use Proxmox, VMware, Hyper-V, Linux, Windows Server, or vendor-managed platforms. The specific product matters less than the restore evidence.

For each VM host, record:

• host hardware,
• management address,
• VM list,
• purpose of each VM,
• storage location,
• backup schedule,
• snapshot policy,
• licence status,
• admin access,
• restore test date.

Do not assume that a VM backup exists because the host has snapshots. A snapshot can help with rollback, but it is not a complete disaster recovery plan if the host, storage pool, or rack loses power or fails.

Media storage can be large and operationally important without being safety-critical. Plex libraries, Kaleidescape systems, music libraries, IPTV assets, movie servers, and AV content folders may affect guest experience and charter readiness.

Treat media storage differently from business or technical records.

Ask:

• Is the media replaceable?
• Is metadata worth preserving?
• How long would rebuilding take?
• Is the library local, cloud-managed, or vendor-managed?
• Does the AV system depend on the same NAS as business files?

Do not let guest media consume storage or backup capacity needed for technical records, owner office documents, or monitoring logs.

Monitoring servers often look optional until something fails. PRTG, Zabbix, vendor dashboards, syslog collectors, firewall log exports, switch monitoring, UPS monitoring, and environmental monitoring can become important evidence during outages.

For monitoring systems, record:

• what is monitored,
• who receives alerts,
• how long logs are retained,
• whether time synchronisation is correct,
• where configuration backups are stored,
• what happens if the monitoring server itself fails.

Logs are only useful if timestamps are reliable. Make sure servers, NAS units, firewalls, switches, and monitoring tools use a sensible time source.

Backups fail most often when nobody owns the restore.

For each system, define:

• source data,
• backup destination,
• backup frequency,
• retention period,
• encryption method,
• offsite or cloud copy,
• restore owner,
• last restore test,
• recovery priority.

Do not only ask whether backups run. Ask what the yacht can restore and how long it will take.

A backup job that has never been restored is an assumption. A backup job with a tested restore is evidence.

Yacht teams often use the word "backup" for several different things. That creates confusion during a failure.

A snapshot can help roll back a mistaken deletion or a bad update, but it usually depends on the same storage system being healthy. A replica can help if the primary storage fails, but it may also replicate bad changes. A cloud sync folder can make files available ashore, but it may also synchronise deletion, encryption, or permission mistakes. A cold offline copy is slower to use, but it can be valuable if ransomware, account compromise, or a failed storage pool affects the live system.

The practical approach is to record what each protection layer is actually for:

• quick rollback for user error,
• local restore after hardware failure,
• offline recovery after cyber incident,
• offsite copy after fire, flooding, theft, or major equipment loss,
• archive retention for compliance, insurance, or owner-office history.

Do not let one tool pretend to solve all of those jobs. A yacht may not need enterprise-scale disaster recovery, but it does need an honest answer to "what can we recover if this rack is unavailable?"

Not every dataset needs the same recovery time.

A practical priority model:

• immediate: admin credentials, firewall/switch configs, active technical records, owner office essentials,
• same day: crew admin files, PMS/procurement records, monitoring configurations, key vendor software,
• next few days: media metadata, historical logs, archive folders,
• lower priority: replaceable entertainment files or old project copies.

This is a management decision as much as a technical one. Technical crew can explain the options, but captains and managers should decide what business continuity requires.

Restore testing does not need to be dramatic. It can be a small, controlled proof that the yacht can recover a file, a folder, a configuration export, a virtual machine, or an application database.

Useful restore tests include:

• recover one deleted shared folder to a temporary location,
• restore a firewall or switch configuration file into a lab copy or spare device,
• recover a virtual machine backup without touching production,
• restore a NAS snapshot and confirm permissions still make sense,
• download a cloud backup while the yacht is using a constrained WAN link,
• confirm that backup encryption keys and admin credentials are available to the right people.

Record the result. If the restore test required one specific vendor engineer, one forgotten password, or a shore connection the yacht may not have at anchor, that is not failure. It is useful evidence. The fix is to document the dependency and decide whether it is acceptable.

A yacht's main NAS fails during a guest trip. The AV team says the movie library is offline. The captain asks whether anything operational is affected. The ETO checks the storage register and sees that the same NAS also holds technical drawings, network backups, and the monitoring server database.

Without that register, the problem might be treated as an entertainment issue.

With the register, the team can prioritise correctly. Guest media can wait if needed. Network configuration backups and technical records should be copied from the latest backup first. The monitoring database can be restored to a temporary VM if the outage affects fault-finding.

The value of the register is not paperwork. It changes the recovery decision.

Do not use the same NAS as primary storage and the only backup target for the same data.

Do not assume a cloud sync folder is a backup. Deletions and ransomware can sync too.

Do not let old vendor admin accounts remain on NAS and server systems.

Do not store technical documentation only inside the system it is needed to recover.

Do not forget UPS monitoring. A storage system that shuts down badly during every power event will eventually create a bigger problem.

Do not leave restore knowledge with one engineer or one shoreside vendor.