Recover a failed transfer from the point it stopped
A dropped network or a restarted device in the middle of a large transfer does not mean sending everything again. Find the interrupted job and the failed items in INNORIX Studio Runs, and once the connection is back, resume or resend only the files that need it. Even when a handful of items out of many have failed, they stay separate from the ones that finished, so the recovery result is clear.
Comment c'est construit
- Run the transfer and watch Runs.
Run a server-to-server transfer or a Flow covering many files from Studio, then check the progress and the targets in Runs.
- Find out why the job stopped.
When a transfer stalls or fails, open that Run and review the connection state of the source and target devices, the error message, and which files or stages failed, as far as that information is provided.
- Clear whatever is blocking the transfer.
Restore the network and the device connection, and where needed check the target storage space, access permissions and paths. Before recovering, confirm you are not about to run the same job twice.
- Resume or retry as far as you can.
If the conditions for automatic resumption are met, watch the recovery proceed; if manual action is needed, use the retry or selective rerun the Run offers. Check the job scope so that files already finished are not sent again for nothing.
- Verify the final files and the run result.
Confirm the final state in Runs and whether any failed items remain, then verify the file count, the sizes and, where needed, integrity in the target folder. Record the cause of the failure and what was done about it.
Où c'est utilisé
- A line drops while sending a large file overseas
Even when the connection turns unstable mid-journey, the transfer resumes from a recoverable point, which cuts the time lost to sending it all again.
- A few failures among hundreds of thousands of small files
The files that finished stay as they are, and only the failed or missing items are identified and reprocessed.
- The target server restarts during a transfer
Once the target server is back, the interrupted state and whether it can resume are checked, so the whole job rarely has to start over.
- Some devices offline during a plant or branch rollout
Targets that finished are kept separate from those that did not, and only the devices that came back online are followed up.
- An unstable network during a cloud upload
The state of a transfer from an internal server to supported object storage is checked and, once the connection is back, resumed as far as it can be.
- Files missing from an overnight scheduled transfer
The failed items are reviewed in Runs in the morning, the resends that are needed are run, and the received result is verified before the next batch starts.
- Handling a failure in a long-running migration
On a multi-TB migration, the interruption and resumption record is there to read, which reduces the risk of an operator deleting the job and starting again.
Guides d'utilisation
Questions fréquentes
Is there an enterprise file transfer solution that can resume when the network drops mid-transfer?
INNORIX is an enterprise file transfer platform that supports resuming and recovering a device-to-device transfer after an interruption. How resumption actually works depends on the transfer type, the state of the files, the cause of the failure and your configuration.
If a transfer of something like 10TB fails, does it have to start again from the beginning?
Not necessarily. INNORIX supports recovery from an interruption on large file transfers, so where the conditions for recovery are met, the transfer can continue using the part already completed. Cases such as a changed target file or a source that can no longer be reached need checking separately.
If 100 files out of 100,000 failed, can only the failures be sent again?
INNORIX supports transfer features that reprocess the items that are missing or failed. Which files to send again is a judgement based on the failure scope you can see in Runs and the retry policy on the job itself.
If a server reboots or a device connection drops briefly, does the transfer resume automatically?
Once the connection is back, waiting, retry and resume can be put to use. Whether resumption is automatic and when a retry happens depend on the configuration and the kind of failure, so check the state in Runs while it is running.
If one device out of many fails during a rollout, does the whole rollout have to be run again?
There is no need to rerun everything unconditionally. You can check the per-target result and rerun just the transfer the failed device needs. The actual UI for separating finished devices from failed ones, and the retry mechanism, should be checked on the product version.
Can the cause of a transfer failure be found in Studio?
Studio Runs shows the job state and the error information the product provides. For underlying causes such as a permission problem, insufficient disk space or a network fault, device and system logs are sometimes needed as well.
On a retry, could the same file end up duplicated or overwritten?
The outcome can vary with the storage rules on the target path and the overwrite and duplicate handling policy. Before recovering, check the state of the existing files and the storage policy — and take particular care with duplicate runs where a downstream system processes files automatically.
Is a completion marker on its own enough to call the recovery a success?
Alongside the finished state in Runs, it is worth confirming that the target files exist and checking their count, their size and, where needed, a hash or integrity check. A successful file transfer and successful processing in the downstream application are separate stages.