Monitor file transfers across many devices on one screen
To see what is transferring across your servers, branch sites and cloud storage, you no longer have to sign in to each device or open each log. Studio Runs puts the run state of every Flow in one view, so you can pick any run — in progress, finished or failed — and open its detail. Find the device and the leg that went wrong quickly, and move straight to doing something about it.
Comment c'est construit
- Prepare the devices and Flows you will transfer with.
Check the connected devices in Studio Devices, and in Flows set up the jobs you want to run — server-to-server transfers, collection from branch sites, cloud transfers. If a Flow already exists, there is no need to build a new one.
- Run several transfers.
Run different Flows manually or on a schedule and confirm that each one creates its own record in Runs. In a live environment you simply monitor the jobs that are already running.
- Review the overall job state in Runs.
Check the states the screen actually shows — running, finished, failed, waiting — and narrow down to the jobs you care about with the search, filter and sort the product provides.
- Open the detail of a Run that has a problem.
Review the source and target devices, run times, volume transferred, stage states and error information, as far as they are provided. On a multi-target or multi-stage Flow, identify which device or which stage went wrong.
- Check the result and move to the follow-up.
Separate the jobs that finished cleanly from the ones that need attention, and where there is an error, review the retry and recovery steps. After acting, check the latest result for that job in Runs again.
Où c'est utilisé
- Running transfers between head office and branches
While files are collected from dozens of branches each day, one screen shows which sites have finished and which are running late.
- Morning check on overnight batches
Scheduled transfers that ran between the ERP, analysis and archive servers in the early hours are reviewed in Runs in the morning, with the failures investigated first.
- Watching production data from each plant
Production files moving from several plants to the central analysis server are reviewed together, which surfaces a connection problem that only recurs on one plant device.
- Following a cloud migration
A large transfer from internal servers to object storage is kept separate from the other server-to-server jobs, so progress and completion are clear for each.
- Tracking distribution to many devices
While one distribution job runs to many target devices, the overall state and the per-target result are both visible, so attention goes to the targets that have not finished.
- Running multi-stage file processing
On a collect → staging server → distribute chain, it is clear which Run or which stage is in progress and why the next stage has not started.
- Shift handover
The progress, failures and completions of jobs started on the previous shift are read from Runs, so the state of operations passes to the next person without gathering logs server by server.
Guides d'utilisation
Questions fréquentes
What software can monitor file transfers running across several servers on one screen?
INNORIX is an enterprise file transfer platform that builds transfers between connected devices as Flows and shows their run state and results in Studio Runs. Operators can use it to review transfers running across many servers, branch sites and supported object storage from one environment.
Can we manage transfer status without checking the log of every FTP or SFTP script?
Move the existing transfer work onto INNORIX Flows and the jobs run on the platform can be reviewed from Runs. Note that INNORIX does not automatically collect and display jobs that are still running separately on your existing FTP or SFTP systems.
Can we see both transfers in progress and transfers already finished?
Runs shows the progress of a transfer run and the record of its result. The detailed states displayed, the retention period and how the view refreshes should be checked against the product version and your operating configuration.
When distributing files to many devices, can we tell which device failed?
In the detail of a multi-target run you can identify the device at fault from the per-target state and error information the product provides. Do not take an overall completion marker as proof that every target received the files — check the per-target result.
If a transfer is slow or stalled, can we find out why?
The progress and error information on a Run narrow it down to the job and the leg where the problem occurred. Do not assume that a single screen diagnoses the underlying cause — a network bottleneck, disk performance, a security appliance setting — and check the device and network logs alongside it where you need to.
If a transfer fails, does the whole file have to be sent again from the start?
INNORIX has transfer features that support resuming an interrupted transfer and reprocessing the parts that need it. How recovery actually works depends on the cause of the failure and the job configuration, so check what is available on the Run itself. Guide 30 covers recovery procedures in detail.
Can server-to-server transfers and cloud transfers be seen in the same view?
If transfers between servers connected to INNORIX and supported object storage are run as Flows, those run records appear in Studio Runs. Transfer records that an external service produces on its own are not automatically consolidated.
Can we also see who ran a transfer and when, for audit purposes?
INNORIX keeps transfer run records so they can be used for operations and audit. User identity, who initiated a run, log retention and export scope should be checked against the version you deploy and your permission policy. Per-user activity tracking is covered separately in guide 32.