Storage and backup planning

Dedicated servers for storage workloads, with directly attached NVMe

OnuCloud servers are located in Tokyo, Japan.

Do shared-disk fluctuations affect queries, or do compression and verification during backup windows compete for CPU? Identify the bottleneck first, then plan drive layout, memory, and recovery bandwidth. Dedicated hardware does not replace redundancy planning.

The sections below assess hosts, data services, backups, and workload access in turn. No single configuration can replace an evaluation of the workload.

VMs and host resources

Reserve resources for the host before sizing VMs

Proxmox VE is a good fit for running multiple long-lived services on one dedicated machine. Resource ownership is clear, but VM quotas, network isolation, and backups still need to be configured independently.

Compute can be allocated, but physical resources are finite

The AMD EPYC 7543P provides 32 cores and 64 threads, supports AMD-V and NPT, and allows nested virtualization. Nested environments are useful for testing virtualization configurations, but additional scheduling layers add overhead. Support for nesting does not mean there is no performance impact.

128GB DDR4-3200 ECC suits hosts with clearly defined resource requirements. For larger VM counts or more room for ZFS ARC, consider the 256GB tier. CPU allocations, host headroom, and memory budgets all need to be planned together; thread count alone is not a sound basis for sizing instances.

Memory cannot be upgraded on the existing machine after provisioning. Changing tiers requires a new order and a self-managed migration.

Keep workload disks and backup volumes separate

VM disks can use the two included 1TB NVMe drives, each directly attached. Choose whether to use them independently or configure a mirror based on recovery requirements. Optional 2TB NVMe drives can serve as backup volumes; up to two can be added, each also directly attached.

On-machine backups make routine rollbacks easier, but share the same hardware failure boundary as the workload. Important copies should also be transferred off-site. Placing a backup in another VM does not change the fact that it remains on the same physical machine.

Suitable for administrators who can manage a virtualization host. Not intended for projects that expect hosted VM management, backup planning, or system configuration.

Databases and middleware

Remove shared-storage contention without skipping high-availability planning

Database queries, index builds, log writes, and persistent caches have different disk latency requirements. Directly attached NVMe avoids shared storage, eliminating fluctuations caused by other customers competing for shared cloud disks. Application locks, query plans, and tasks on the same machine can still affect latency.

Good fit: sustained writes and a predictable working set

Dedicated hardware makes resources easier to allocate when databases and middleware run continuously and need clearly assigned CPU, memory, and disk resources. Allocate memory for database buffers and the cache working set first, then leave room for the system, log processing, and backup compression.

Backup scans and verification can compete with application queries for disk and CPU, even when they belong to the same customer. Schedule tasks around workload lulls rather than assuming dedicated hardware means every task can run at full load simultaneously.

Poor fit: treating a single machine as automatic disaster recovery

Two directly attached drives are not delivered as a RAID-1 array. Services that need failover, mirroring, or recovery across devices require a self-managed plan for replication, failure detection, and recovery. Separate drives in one machine alone do not provide high availability.

OnuCloud provides the hardware and network; customers are responsible for database settings, replication topology, and data backups. Datacenter-managed redundancy or database administration falls outside the scope of this service.

Files and off-site copies

Assign drives by recovery needs, not just total capacity

File storage is about usable space; backup services also need isolated copies and a recovery path. The two included 1TB NVMe drives provide 2TB of raw capacity in total. A two-drive mirror provides about 1TB of nominal usable capacity, before formatting and filesystem overhead.

Capacities are based on the nominal specifications. Hardware RAID is not included; customers create pools and mirrors themselves.
Drive group Suggested role Capacity Important limitation
Included: 2 × 1TB NVMe ZFS mirror for hot data and frequently used files 2TB raw; about 1TB in a two-drive mirror A mirror does not replace historical versions or protect against synced deletions
Optional: 2 × 2TB NVMe Create a separate backup pool for workload copies 4TB raw; about 2TB in a two-drive mirror Still an on-machine copy; critical data needs a separate off-site backup
External off-site copy Keep data outside this machine's failure boundary Depends on the independently arranged backup destination Regularly verify readability, recovery order, and the time required
Cross-border workloads and fixed egress

Assign addresses to services; enforce isolation in the system

A fixed egress address is useful for store backends, service callbacks, and IP allowlists. A dedicated IPv4 address provides clear address ownership, but the number of addresses does not automatically create workload isolation or prevent reviews and risk checks by external platforms.

Good fit: multiple services with clearly defined address mappings

One dedicated IPv4 address is included, with up to 255 additional addresses available, for a maximum total of 256. Maintain an address inventory by VM or service, recording each address's purpose, assigned resource, and access rules to avoid duplicate configuration.

Additional addresses must be bound within the system. Remote management uses only the first IPv4 address shown in the control panel; assign the others according to workload requirements. Customers configure the firewall, forwarding, and VM networking.

Poor fit: treating multiple IPs as deployment across multiple locations

Adding IPv4 addresses to one machine does not provide geographic distribution or change the machine-level failure boundary. Architectures that require deployment across multiple cities, cross-region failover, or access close to users in different regions should not rely on a single machine for every role.

When multiple store backends run on the same machine, manage accounts, credentials, and service permissions separately. Network addresses can be assigned, but system permissions and compliance requirements still need to be handled individually.

Windows workloads

Confirm licensing before planning remote access

Applications that depend on Windows Server can use Standard or Datacenter licensing, billed monthly. This suits workloads with existing Windows administration expertise and the capacity to install applications and maintain the system independently; it is not a managed application or administration service.

Operating system versions and access

Windows Server is available in versions 2019, 2022, and 2025, with English, Traditional Chinese, or Simplified Chinese as the system language. After provisioning, find the credentials in the control panel and connect using RDP. If multiple IPv4 addresses are assigned, remote connections use the first address only.

Check that applications, drivers, and dependencies are compatible with the selected operating system version. A system language option does not mean an application has been localized; confirm the application's language support and licensing separately.

A license does not replace application configuration

Choose Standard or Datacenter based on actual licensing requirements, not memory capacity alone. If Windows and Linux workloads are to share one machine through virtualization, separately verify which guest operating system licenses apply.

Preinstalled proprietary business software, directory service configuration, and managed application accounts are outside the standard service scope. Before ordering, list software dependencies, access requirements, and backup methods, then confirm that the operating system and hardware meet those needs.

When a full machine may not be the right fit

For light workloads, dedicated hardware may not be the best value

OnuCloud dedicated servers suit workloads that use resources continuously, have clear requirements, and can be managed independently. If the bottleneck is not dedicated compute, directly attached storage, or a fixed egress address, a dedicated server may add idle capacity and operational work.

  1. 01

    Only a few cores are needed for testing

    For small compute tasks, light disk activity, and test environments that can be released as soon as a job finishes, a general-purpose shared VPS is often better value. If the 32 cores and 64 threads remain idle, the benefits of dedicated hardware are hard to turn into practical gains.

  2. 02

    Resources need to scale instantly

    For workloads that add or remove instances by the hour, or need large temporary increases during an event, evaluate elastic services first. Changing memory tiers here requires ordering a different machine, so scaling the existing machine is not a way to handle sudden traffic spikes.

  3. 03

    System administration expertise is unavailable

    Software RAID, ZFS, virtual networking, and data recovery all require ongoing administration. If a project cannot take responsibility for system configuration and backup verification, that operational capacity should be addressed first; dedicated hardware is not a managed service.

A different kind of compute workload

DGX Spark for model experiments and CUDA development

For local LLM inference, LoRA / QLoRA fine-tuning experiments, and AI application prototyping, consider DGX Spark. It is not an accelerator option for AMD storage servers; the two product lines are selected separately.

Good fit: development with a clear experimental goal

For model output comparisons, inference workflow validation, fine-tuning experiments, and CUDA development, define evaluation goals and how results will be exported before deciding whether a full-machine environment is a fit. Models and development dependencies must be prepared independently.

Poor fit: x86 environments or multi-machine training

Projects that depend on x86 software, Windows environments, or multi-machine training should not move directly to this product line. Check architecture and software compatibility before planning model experiments, so migration costs are not overlooked.

Confirm drive layout and recovery goals before choosing options

Record hot-data capacity, backup locations, memory working sets, and recovery bandwidth, then open the OnuCloud configuration page to select options. Set redundancy and backup plans alongside the machine configuration.