Move Files Between Your Own Servers, and Never Lose Metric History

Two new tools just landed in the QuickBox Pro dashboard, and they solve two problems that used to mean a terminal session and a bit of luck. The first moves your data between your own servers. The second makes sure your server's history is always there when you go looking for it.

Say you have two QuickBox Pro servers, both on your account, and you want to move a library from the old box to the new one. Or you have grown out of one server and want to spread the load across two. Until now that meant SSH, an rsync you had to babysit, and hoping nothing dropped halfway through. Inter-Instance Transfer does the whole thing from the dashboard.

You will find it in the sidebar under Transfer. It moves a folder tree directly from one of your servers to another, with no SSH, no manual rsync, and no third-party relay in the middle. The two servers talk to each other and nobody else.

The page has four tabs - Send, Incoming, History, and Settings - and the flow is always the same, because data only moves once the receiving server agrees to it:

1. ●Send. On the sending server, browse to the folder you want to move, pick the destination server from your own connected instances, and choose whether this is a migration (you are moving everything to the new box) or a load balance (you are spreading content across both). Then create the offer. Nothing has left your server yet.
2. ●Incoming. The offer shows up on the receiving server's Incoming tab. You review it and either approve or reject it.
3. ●Pull. When you approve, the receiving server pulls the data across and a live progress view opens - bytes moved, files done, throughput, an ETA, and a pause button. The receiver does the pulling, which is the whole reason the destination is chosen on the receiving side.

If the connection drops mid-transfer, it resumes from where it left off, and everything that arrives is checksum-verified before it is committed. A large migration can take hours, and it is built to survive the bumps that come with that.

Beyond the Transfer page, the System Dashboard now carries a live Inter-Instance Transfers cockpit. It is the at-a-glance view of everything moving to and from this server right now:

• ●A summary strip with the number of active transfers, the aggregate speed, and the bytes in flight.
• ●A live sender to receiver node-map showing this server and the peers it is exchanging data with.
• ●A row per active transfer with the user, the direction, the peer, size and percent complete, file count, elapsed time, average and live speed, and status.

You drive transfers from the Transfer page and you watch them from the cockpit. The cockpit shows activity for this server and its paired instances only - it is not a fleet-wide view.

The History tab keeps a searchable record of every transfer, with per-transfer analytics and a throughput-versus-host-load chart, so you can see not just what moved but how it behaved against everything else the server was doing at the time.

On the receiving end, History also tracks the verification lifecycle and lets you re-apply ownership, so the destination account cleanly owns its migrated data and its apps can pick it up right away.

A few things are true about every transfer, and they are worth stating plainly:

• ●Same account only. A transfer can only happen between two servers registered to the same license owner. Every request is filtered to your own instances on the server side, so there is no path to reach anyone else's box.
• ●Receiver pulls, sender never pushes. The sender only makes an offer. The receiving server dials the sender and pulls, so only the sender's address is ever needed and the receiver's stays private.
• ●Signed, single-use, expiring authorization. Each transfer is authorized by a cryptographically signed (Ed25519) grant minted by the QuickBox broker. The grant is single-use - consumed when the transfer completes - and it expires after 12 hours. Long enough to finish a big migration, never a standing credential.
• ●Mutual TLS between the two servers. Both servers pin each other's certificate fingerprint, carried inside that signed grant, so a stolen grant is worthless to anyone who does not also hold the receiving server's private key.
• ●No address shown in the dashboard. No screen, not the Transfer page and not the cockpit, ever renders a peer's IP, host, or port. Servers appear by a friendly name or an opaque id.

One honest note, because we would rather be straight with you than oversell it. Because the connection is direct, with no relay sitting in the middle, the receiving machine necessarily learns the address it dials to reach the sender. That is unavoidable without adding a third-party relay, which we deliberately left out. What is guaranteed is that the other person never sees a server's address anywhere in the interface, and that an intercepted authorization grant is useless without the receiver's private key. It is not a claim that the peer server never learns a reachable address.

Inter-Instance Transfer ships off. Until an administrator enables it under Settings > General, the Transfer entry stays hidden and the feature is unavailable. It is an administrator feature on both surfaces - the page and the cockpit both require an admin and enforce same-owner scope on every request.

By default an incoming transfer lands in the receiving user's own storage. An administrator can instead point it at an absolute path on the receiving server at approve time, and that choice is honored only for the highest-tier administrator, must be a real directory, and is audited.

Once it is on, the Transfer page's own Settings tab is where you name your server, auto-advertise it to your other instances, browse the connected-instance directory, and tune the transfer engine.

The dashboard is the control surface for transfers - creating, approving, and monitoring all live on the Transfer page. There is one command-line touchpoint for administrators: qb transfer peer-allow, qb transfer peer-deny, and qb transfer peer-list manage a small allowlist so a long transfer between two servers does not trip each other's Fail2Ban and cut the byte path off. The dashboard maintains that allowlist for you automatically when a transfer is accepted, so you rarely need the commands directly.

The second tool is quieter, but if you have ever opened your metric charts after a restart and found the history gone, you will appreciate it.

The System Dashboard has always shown you live CPU, memory, network, and disk graphs. The Telemetry History Store is what keeps the history behind those graphs from disappearing. It is a durable, on-server database of your metrics, and it means your history charts stay gap-free across service restarts, dashboard updates, a reinstall of the main database, and Redis being absent. You will find its panel on the System Dashboard, below the live charts.

The store records nine system metrics: CPU, memory, network, disk usage, disk I/O, load average, swap, GPU, and temperature.

Every sample is written into four retention tiers at once, so the further back you look, the more compact the data gets. A running average lives in the database, so those rollups survive a restart too, and charts automatically read whichever tier fits the range you ask for.

The panel opens with a summary row - total rows stored, on-disk size, the number of tiers, and a live health status. Below that, one card per metric shows a coverage ring for how much history is preserved, a health pill, the total span held, the row count, which chart or feature the metric feeds, and a small table of each resolution's retention and newest sample.

Two cards behave a little differently, on purpose:

• ●GPU is sampled only while the Streaming Dashboard is open, so GPU history is naturally intermittent. When those samples age out the card shows a neutral Idle, not a red warning.
• ●Temperature only appears if your host reports a CPU temperature. Sensorless virtual machines and containers simply have no temperature card, and that is expected.

When you genuinely want to start fresh, a confirm-gated Clear history button wipes the stored history. Your live charts keep updating; only the historical ranges reset until data builds back up.

This is worth being clear about, because "telemetry" can mean two different things in QuickBox Pro. The Telemetry History Store is entirely local. It lives in its own database file on your server, it is a read-only observer of the live samplers so a storage hiccup can never interrupt your monitoring, and it never transmits anything off the machine. It is separate from the account-dashboard telemetry your server reports over the heartbeat - that one is opt-out and documented on its own page. The history store is just your server keeping its own records for you, and it is visible to administrators only.

Both features are documented in full:

• ●Inter-Instance Transfer guide covers the full Send, approve, and pull workflow, ownership of delivered files, the live controls, and the security model.
• ●System Monitoring covers the live transfers cockpit and the Telemetry History Store panel in full.
• ●qb transfer CLI reference covers the peer allowlist commands.

Open Transfer in the sidebar (an administrator turns it on once under Settings > General). Move a folder tree straight from one of your servers to another, migration or load-balance, with no SSH and no relay, and watch it live on the System Dashboard. It is same-account only, the receiver pulls, and no server address is ever shown in the dashboard. And on that same System Dashboard, the Telemetry History Store now keeps your metric history gap-free across restarts, deploys, and reinstalls, on the box and never phoned home. Both are here now.