Trantor® TVStor delivers the block/file/object storage your company needs, and does so on-premise and without vendor lock-in. And you can buy the hardware from us, or through your trusted supplier, because we run on standard servers.
Why Trantor® TVStor
Traditional SAN and NAS systems all follow the same script: a pair of proprietary controllers, expansion modules from the same vendor, limited scalability and redundancy, and then in the end, when you want to change vendor, the migration puts the whole infrastructure under strain. TVStor changes the script: a SAN/NAS made of software and standard servers, scale-out instead of scale-up, supplied as a bundle with our hardware, or installed on servers you buy wherever you like or already own. And it is no ordinary storage: iSCSI/NVMe block storage, S3 object storage, a complete NAS with collaborative Office editing from the browser, and the role of HA gateway for the SANs you already own.
Another form of SAN/NAS
A software appliance on standard hardware: it arrives turnkey on standard hardware supplied by us, or it is installed on the servers you already own, and becomes a working SAN, managed from its console.
The experience is still that of a SAN: volumes, LUNs and hosts are administered with the vocabulary and the protocols your systems already know.
Two engines, one SAN: Ceph for limitless scale-out, or TVStor MultiSCSI, Trantor orchestration on open formats, to start from as few as two nodes.
Two engines, one choice
Ceph engine, from 3 nodes
The same engine behind some of the largest storage clusters in the world: synchronous replicas or erasure coding, self-healing, continuous integrity scrubbing, automatic rebalancing and scale-out with no practical limit. The natural choice when growth has no ceiling.
TVStor MultiSCSI engine, from 2 nodes
Trantor’s own replication and high-availability orchestration, on open formats, MDADM, LVM and NVMe/TCP: the disks stay readable even outside TVStor. The same conceptual family as LINSTOR + DRBD, on a modern, clean base. It starts from two nodes, with the HA limits that two nodes entail, stated openly, and grows into standard odd-numbered clusters.
Linear growth: capacity and performance are added node by node and disk by disk, with online rebalancing, without downtime, without replacing what is already there.
«The complexity of the engine stays under the hood; TVStor gives you a simple, clean interface.»
Feature overview
Block, object and file storage, all from the same dashboard.
Block storage
iSCSI, NVMe/TCP, FC and FCoE with multipath (MPIO): every host connects with its native initiator, over redundant paths
SAN-style management: pools, volumes, LUNs, mappings and masking per host, the mental model you already know
Thin provisioning: volumes consume only the space actually written
Instant snapshots that are space-efficient, manual or scheduled, with retention
Writable clones from snapshots, for testing, development and restarts
Online expansion and shrink, with explicit confirmation
QoS per volume: IOPS and bandwidth limits for noisy neighbours
Per-pool compression on the Ceph engine, and multiple storage pools under one console
Object storage
Native S3 endpoint: application buckets alongside the volumes, same machine and same console
Object Lock for immutability on the destination side, with accounts and keys in the encrypted keystore
The chain stays in-house: TVStor’s immutable backups can point at TVStor’s own object store
Standard S3 API: applications that speak S3 cannot tell the difference
File storage
NFS v3 and v4 for the Unix world and for virtualization
SMB for Windows and macOS clients, with Active Directory / LDAP and Kerberos
Sandboxed SFTP, for secure exchanges and automation
Rich ACLs, NT, POSIX and NFSv4, mapped correctly between the two worlds
Quotas per share and per user, declared and enforced
Previous Versions (VSS) from snapshots: users do their own restores, from their File Explorer
File explorer in the web browser
Drive-style folders and navigation, from the browser, with no client to install
Upload and download, even of entire folders, in both directions
Previews of documents and images, before opening
Real-time collaborative Office editing: several people on the same document, from the browser
The same users and the same ACLs as the NAS: permissions are not duplicated, they are inherited
Everything stays on-premise: files never leave your SAN
Network services
FTP and FTPS to the shares, for the legacy flows that never die
PXE boot with built-in TFTP and DHCP: the NAS that also boots your servers
A service IP that follows the failover: clients never notice which node they are on
Architectural honesty: on the pair the file service is active/passive; file scale-out is CephFS’s job
Technical overview
Architecture
A TVStor cluster can be made of a minimum of 1 node up to a maximum of 7 nodes (inside it, any Ceph/MultiSCSI clusters created have their own specific limits: Ceph from 3 to 7 nodes, MultiSCSI from 1 to 4 nodes).
vDisk: local disk management
TVStor appliances can use local disks in these ways: a local disk is divided into several chunks of equal size (for example, a 1024GiB disk can be split into 16 chunks of 64GiB), after which RAID 0/1/5/6/10 volumes can optionally be created across the chunks of the various disks (example: I have disk1 with 10 free chunks of 32GiB and disk2 with 12 free chunks of 64GiB; I can create a RAID1 volume that uses 4 chunks of disk1 and 2 chunks of disk2, and in total the RAID volume has 128GiB usable; a RAID volume is always applied to chunks of different disks). Once the physical environment is prepared, vDisks can be created, which are the unit on which the Ceph/MultiSCSI clusters inside TVStor are built. A vDisk can use either a whole RAID volume (created beforehand) or one or more chunks of a single disk, which are aggregated (e.g. I can have vdisk1 using raidvol1 and vdisk2 using 4 chunks of disk1).
vDisk: remote disk management
A vDisk, besides being based on RAID volumes and local chunks, can also point to an external LUN: in practical terms, a LUN exposed by an external SAN (over iSCSI, NVMe/TCP, SCSI/FC, NVMe/FC, NVMe/RDMA, with multipath too) is associated 1:1 with a vDisk, which can then be used in combination with other vDisks (local or remote) as the base for Ceph/MultiSCSI clusters. A vDisk that uses remote disks has no limitation compared with a vDisk that uses local disks, which also allows TVStor appliances to be diskless, for example to provide high availability for external multi-vendor SANs.
Clusters with the Ceph engine
TVStor allows the creation and management of one or more independent Ceph clusters. For each Ceph cluster: MON/MGR/MDS can be deployed and distributed across the various TVStor nodes, and vDisks can be used as OSDs (note: a vDisk can be used in only one way, either as an OSD of a Ceph cluster or as a disk of a MultiSCSI cluster, and cannot be shared). On Ceph clusters you can also check the detailed health status, set flags on the OSDs, manage the maintenance of the Ceph services, explore the existing pools (which are created through TVStor’s volume management, described further below) and the objects inside the pools, and manage the CRUSH rules and the CRUSHMAP. Naturally, a Ceph cluster uses a quorum, and needs at least 3 nodes (at least 5 recommended).
Clusters with the TVStor MultiSCSI engine
TVStor MultiSCSI is a proprietary TVStor engine, based on open-source technologies and formats so that the data can be read even without TVStor. MultiSCSI has the following operational differences from Ceph: it also works with one or two nodes (and up to 4 nodes) and has an active/standby architecture (whereas Ceph can serve reads/writes from all nodes). TVStor MultiSCSI works by using NVMe/TCP (or NVMe/RDMA) for the internal sharing of local disks among the various nodes, and uses LVM and MDADM for data replication. Data safety is guaranteed by a sophisticated fencing system (STONITH model) that can use, in cascade, BMC/IPMI, UPS/PDU and network switches to isolate the other node in case of failure. In this way MultiSCSI makes it possible to have three-node clusters that keep working even when two nodes go down. MultiSCSI clusters can optionally use a quorum instead of fencing when they are made of three or more nodes, or of two nodes plus an external witness (software or hardware).
Volume management
Volumes are the data containers used to deliver block/object/file storage. A volume can be created on either a Ceph or a MultiSCSI cluster. In the Ceph case, a volume is materialized as a pool or as a CephFS volume, depending on whether the volume is used for block/object or for file storage. In the MultiSCSI case, volumes are always materialized as blocks (which, for file storage, are formatted normally, since MultiSCSI is active/standby and does not need distributed filesystems such as GFS/OCFS). As soon as it is created, a volume waits to be materialized until it is given a purpose (through LUN/bucket/filesystem management); once materialized it cannot serve other purposes, but it stays intact if the LUN/bucket/filesystem is destroyed, so that the destruction of data is made explicit by deleting the volume. QoS, compression, encryption at rest, replication and backup policies, and so on, are applied on volumes.
LUN, S3 bucket and filesystem management
Volumes are not exposed externally as they are: they are assigned a role/purpose. A volume can be turned into a LUN and exported simultaneously over iSCSI, NVMe/TCP, SCSI/FC, NVMe/FC, NVMe/RDMA, using multipath too; for each LUN, connection ACLs from the outside can be defined (IP whitelist, initiator credentials, etc.). A TVStor volume can also be used as an S3 bucket to serve objects instead of blocks; here too the various policies and access credentials for the S3 bucket can be defined. Finally, a volume can be used as a filesystem, to be exposed through NAS protocols such as NFSv3/4, CIFS/SMB, FTP/FTPS, TFTP, SFTP; for filesystems, both POSIX and NT ACLs are supported, with integration towards external LDAP/AD for authentication and permissions.
Authentication and user permissions
TVStor appliances have both an internal database of local users (shared across the whole TVStor cluster) and the ability to authenticate users through an external service. External authentication can be based on LDAP/LDAPS (username+password bind), RADIUS (username+password, username+password+challenge, 802.1X EAP-TLS / EAP-TTLS-PAP / EAP-TTLS-GTC / EAP-PWD / EAP-PEAP-GTC), OpenID Connect (also with device-code, PKCE, CIBA), SAML 2.0. As for multi-factor authentication (MFA), for local TVStor users an internal MFA using TOTP can be configured, or an external MFA can be configured through a bridge/plugin. For non-local users (LDAP/RADIUS/OIDC/SAML), MFA must be configured on the external authentication server. Login to the services exposed by TVStor differs by service: for LUNs (iSCSI/NVMe TCP/FC/RDMA) and for S3 buckets, login is through static credentials configured on TVStor. For access to the TVStor dashboard, the user can use username/password, TOTP/challenge, and OIDC/SAML redirect depending on how that user’s local/external authentication is configured. For filesystems (NFS/SMB/FTP/SFTP/TFTP) authentication changes according to the protocol.
Web interface to explore the filesystems
TVStor appliances expose, to every user who has access to at least one filesystem, a web interface through which they can explore the files on the shares they have access to, preview some files in the browser before downloading them (such as images, videos, PDFs), upload files and folders, download single files or entire folders (as ZIP), and edit Office Word/Excel/Powerpoint documents from the browser (in collaborative mode too). All on-premise, of course, like the rest of TVStor’s functionality.
DHCP/PXE network services
TVStor appliances can deliver DHCP and PXE services to allow external devices to boot from the network, using the TFTP filesystems TVStor can serve. The DHCP offered by TVStor is DHCPv4 only, and TVStor can also integrate with DHCP servers already present in the infrastructure, by changing the configuration of options 66/67 (next-server and BIOS/UEFI boot file) so that devices booting from the network land on the TFTP served by TVStor. If instead you want to use the DHCPv4 server built into TVStor, the supported features are: one or more assignment ranges, lease duration, optional default gateway (option 3), one or more optional DNS servers (option 6), optional domain (option 15), and of course options 66/67 for PXE.
High availability and load balancing
A TVStor cluster is made of one or more TVStor appliances. If the cluster has only 1 node, there is neither high availability nor load balancing; the only usable engine is TVStor MultiSCSI, which operates only on the local disks of the single node or on remote disks of external SANs. When the number of nodes is 2, high availability is achieved through STONITH fencing: the two nodes are configured active/standby with synchronous replication of configuration and state; when a node stops communicating with the other, it first tries to bring the peer down through several methods in cascade (BMC/IPMI, UPS/PDU, network switch), using a mechanism that prevents two split-brain nodes from bringing each other down; once the other node is marked as off/isolated, the secondary takes the primary role, or the primary carries on without waiting any longer for the acknowledgment of the replicas on the secondary node. This mechanism is used not only for the local database holding configuration and state, but also for the disk replicas of the MultiSCSI engine. With two nodes, a software or hardware TVStor Witness can be deployed to let the cluster achieve HA through quorum rather than fencing.
When the node count reaches 3 or more, the witness role can be taken by one of the three TVStor nodes (this holds both for the HA of the database and for the HA of the MultiSCSI engine). Optionally, fencing can be enabled as a fallback inside a MultiSCSI-only cluster of 3 or more nodes, to survive the loss of quorum (so a 3-node TVStor cluster using only MultiSCSI can use the built-in witness to degrade quickly when it loses one node out of three, and then fall back on fencing to keep operating with one node out of three). Load balancing with the MultiSCSI engine is obtained by alternating the primary nodes of a cluster between one node and the other (e.g. a two-node TVStor cluster, where one MultiSCSI cluster has node1 as primary and node2 as secondary, and another MultiSCSI cluster has node2 as primary and node1 as secondary; they collapse onto a single node only when there is a failure or maintenance). Ceph clusters created inside TVStor work differently: first of all, they need at least 3 nodes (5 recommended); the Ceph model is not active/standby but mostly active/active, so load balancing is native in every Ceph cluster; when a TVStor cluster contains Ceph clusters, fencing cannot be used as a mechanism (so any other MultiSCSI clusters use quorum only for HA).
Below, an animated failover sequence.
Healthy cluster: 5 objects, 3 copies each. Click a node to switch it off.
Diskless TVStor appliances and HA for external SANs
A TVStor cluster can provide high availability to external SANs (multi-vendor too), by exploiting the fact that a TVStor appliance can use external LUNs as vDisks as well, which also allows effectively diskless configurations of an appliance. An example architecture: in rack1 we have SAN san1 from vendor1, in rack2 we have SAN san2 from vendor2; we install two diskless TVStor SANs, san3 and san4, one in each rack cabinet, and configure them to provide HA for the existing SANs san1/san2; this way the external applications connect to the TVStor SANs san3/san4 instead of the existing ones, and should a rack cabinet go down, the HA delivered by TVStor lets the external applications keep reaching the LUNs etc. of SANs san1/san2.
Multi-tenant management
TVStor provides an optional subdivision into tenants, to allow certain users to administer only a portion of the storage infrastructure. Tenants can be assigned disk usage quotas and QoS, and for each tenant you can specify which features are enabled (among LUNs, S3 buckets and filesystems). A tenant cannot administer Ceph or MultiSCSI clusters; it can only create volumes (within its quotas and on the clusters allowed) and manage the services exposed on the volumes (except DHCP/PXE). The compression, encryption, backup and replication policies on a tenant’s volumes can be decided either by the TVStor administrator or partially delegated to the tenant administrator.
Backup, replication and data protection
Backup and replication
Synchronous replicas between the nodes, or erasure coding on the Ceph engine, with failure-domain awareness
Asynchronous remote replication to a second TVStor cluster, for disaster recovery
Smart incremental backups (CBT): only the changed blocks travel, to local or S3 repositories, with chained restore
Immutable backups, even for admins: in governance mode our API refuses deletion to anyone, admins included; compliance mode adds S3 Object Lock. Retention periods, once set, are never shortened, an honest boundary: inside the SAN we are the guarantee, outside it is encryption that guarantees
Automatic rebuild on the loss of disks or nodes, with guided disk replacement
Failover demonstrated, not promised: cascading fencing, BMC, switch, PDU, and the third vote of witnessd (a Raspberry will do): no acknowledged write ever lost, never two primaries
Operational security
Encryption at rest and in transit, as standard: LUKS2 and dm-crypt, AES-256-GCM keys in the vault, unattended unlock at boot
Locked-down appliance: no SSH access by default; emergency credentials and encryption recovery keys are generated straight into the vault, under supervision
Protected volumes: a mapped volume cannot be deleted by mistake, explicit confirmations are required
Roles and audit: deny-by-default, delegation, and every operation can be reconstructed
Rolling updates: maintenance flows node by node, the volumes stay served
Built-in monitoring and alerts on capacity, health and latencies, with capacity-growth trends
Encryption, immutability and demonstrated failover come as standard, not as options on a price list: for defence, public administration and healthcare, protection is part of the design.
Bundled TVStor appliances
One idea only: the building block, a complete standard server, x86 or ARM, with every TVStor feature. On its own, as a mirrored pair in separate racks, or in a cluster: you compose the topologies. And every element of the code declares what matters.
appliance, 1st gen. hardware
single-node building block
NVMe U.2 PCIe 5.0 · DWPD 1
Media codes: U2 = NVMe U.2 · M2 = M.2 NVMe · ST = SATA3 SSD · HD = 7200 rpm HDD (M/H = medium/high WRL) · D1/D3/D5 = DWPD
| CODE | MEDIA | DWPD | PURPOSE |
|---|---|---|---|
| TVSTOR-AG1-N1-U2D1 | NVMe U.2 PCIe 5.0 | 1 | Capacity, reads and mixed workloads |
| TVSTOR-AG1-N1-U2D3 | NVMe U.2 PCIe 5.0 | 3 | Write-Intensive, continuous writes |
| TVSTOR-AG1-N1-M2D1 | M.2 NVMe | 1 | Capacity in a compact form factor |
| TVSTOR-AG1-N1-M2D3 | M.2 NVMe | 3 | Write-Intensive in a compact form factor |
| TVSTOR-AG1-N1-STD5 | 2.5" SATA3 6G SSD | 5 | Extreme endurance, SATA channel |
| TVSTOR-AG1-N1-HDM | 3.5" 7200 rpm SATA/SAS HDD | — | Cold capacity, WRL 100-250 TB/year |
| TVSTOR-AG1-N1-HDH | 3.5" 7200 rpm SATA/SAS HDD | — | Nearline enterprise, WRL up to 550 TB/year |
The code declares media and endurance, never the terabytes: capacity is configured per project, and you can work out the writes per day yourself (DWPD × installed capacity). The mirrored pair in separate racks, the reference form, is the honest match for a dual-controller «50 TB raw» array: 35-40 TB of real usable space. Other forms and media: on a project basis.
On its own
pure capacity on a standard server, with every feature and the TVStor console.
As a pair
synchronous mirror in separate racks, local RAID 5 and automatic fencing: the reference SAN of the AG1 generation.
In a cluster
multi-node topologies and the Ceph engine, on a project basis.
As a pair, protection comes in three layers: local RAID 5 absorbs the failure of a disk without touching the replica; the synchronous mirror between the racks absorbs the loss of an entire server; automatic fencing excludes one side before the copies can diverge, never two primaries. Chassis, power supplies, fans and racks: all separate.
Endurance is in the product name. In the quotes you will compare, it is often nowhere to be found: ask the supplier to state the DWPD of their disks, in writing.
For every turnkey appliance, the possible expansions, their types, limits and prices, are defined in writing from day one. Growth is not a negotiation: it is a line in the contract you have already read.
TVStor and the alternatives
Every alternative below is a serious product with real strengths. The comparison, though, is not the spec sheet: it is the model, architecture, commercial model, and where your data stays.
| PLATFORM | CONTROL PLANE | LICENSING MODEL | WORTH CONSIDERING |
|---|---|---|---|
Trantor® TVStor Trantor® · Italy | Dual-engine software appliance (Ceph or MultiSCSI): from two nodes to scale-out, on standard servers | Turnkey on standard servers, or installed on yours: the hardware is always yours and replaceable | Encryption at rest and in transit, admin-proof immutable backups, node-by-node growth, open formats: the SAN without its lock-in |
NetApp ONTAP · non-EU | ONTAP controller pairs in HA on dedicated appliances | Proprietary appliances; bundled software, consumption and STaaS (Keystone) | A vast ecosystem, unified SAN and NAS; hardware, shelves and spare parts stay on the vendor’s rails |
Pure Storage FlashArray · non-EU | Dual-controller array with proprietary flash modules (DirectFlash) | Subscription-first (Evergreen), up to storage as-a-service | A meticulously polished operating experience; the hardware is proprietary down to the single flash module, and the exit is a negotiation |
QSAN XCubeSAN · non-EU | Value-tier dual-controller array | List-priced appliances, simple licensing | Aggressive pricing for the mid-market; classic scale-up: growth goes through the vendor’s shelves and expansions |
HPE 3PAR StoreServ · non-EU | Multi-controller mesh, scale-up on dedicated appliances | Off the price list since 2021; support winding down (2026–2027) | A historic line at the end of the road: HPE names Alletra as its successor. The refresh is on the agenda anyway, so you may as well rethink the model |
QNAP · Synology SMB NAS · non-EU | Single-node or paired NAS: filers first, SANs second | List-priced appliances, app ecosystem | Excellent SMB-class filers; enterprise HA and block storage are not their trade |
Nextcloud Files and collaboration · Germany | Sync and collaboration on top of storage you bring yourself | Open source; enterprise by subscription | The reference for sovereign collaboration, but it is an app: the SAN underneath remains a separate project |
IBM SVC Storage Virtualize · non-EU | HA gateway and virtualizer in front of third-party SANs | Dedicated appliances, capacity-based licences | The historic reference of the HA gateway trade; TVStor does it on open formats, with no dedicated appliance |
HPE Alletra MP / GreenLake · non-EU | HPE’s current line: disaggregated MP architecture, heir to Primera and Nimble | Proprietary appliances; commercial push on GreenLake, subscription and consumption | The designated successor of 3PAR: modern and polished, but the model is the same, vendor hardware, multi-year contracts. The merry-go-round starts again |
Positioning summary as of July 2026. Every platform cited is a valid product in its own context of use; trademarks belong to their respective owners.
- «When I need to expand, will I be able to buy the hardware from anyone, or only from you?»
- «Beyond today’s discount: what will expansions and renewals cost me in three years?»
- «If I decide to leave you, how hard will it be to take my data with me?»
TVStor answers in writing.
Zero lock-in. Made in Italy.
Designed and developed in Italy by the same team behind the Trantor family: the people who support you are the people who wrote the code, with a single point of contact for product, roadmap and support.
Freedom on four axes
Hardware: standard servers and disks, no proprietary shelf, no mandatory vendor, not even us: the hardware supplied by Trantor is standard and replaceable too
Data: engines on open formats, Ceph on one side, MDADM + LVM + NVMe/TCP on the other: the disks stay readable on other platforms, not only with our console
Clients: hosts connect with the native initiators and drivers of their operating systems, no proprietary agents to maintain
Growth: you scale and decommission node by node; the forklift upgrade is not a date on the calendar
Made in Italy, for real
Designed and developed in Italy by the same team behind the Trantor family: the people who support you are the people who wrote the code, with a single point of contact for product, roadmap and support. A concrete answer to the technological sovereignty and confidentiality requirements of defence, public administration and large groups: the storage of your data does not depend on decisions taken overseas.
Encryption and immutable backups
Every disk is encrypted at rest, a disk that is pulled out or decommissioned reveals nothing, and every communication between the nodes travels encrypted in transit. Immutable backups, untouchable until expiry, even by an administrator, shut the door on ransomware. For defence, public administration and healthcare, protection is part of the design, not a module.
The Trantor® family
TVirt© for VM and container virtualization, TVStor for storage, VDesk for virtual workstations: three products, one Italian supply chain, a single point of contact for the entire infrastructure.
TVirt for VM and container virtualization, TVStor for storage: one Italian supply chain, a single point of contact.
VDesk for virtual workstations, TVStor for storage: one Italian supply chain, a single point of contact.
Last updated: 10 August 2026. The contents of this page follow the brochure of that revision.
See it in action.
Request a guided demo or a proof of concept on your hardware, in a lab or in your datacenter.