Migrate FTP, SFTP, SCP, and rsync Commands to INNORIX CLI

Migration Preparation

This is a preliminary step to migrate existing ftp, sftp, scp, and rsync commands and their wrapper scripts to the INNORIX CLI (console transfer client, powered by the Exacoola backend). Since the INNORIX CLI is designed to accommodate the command structures of these four tools intact, most of the migration is completed by simply prepending innorix to the commands and replacing only the target notation and authentication method.

Environment Assessment

Description

First, list the tasks to be migrated. You only need to examine the items that are actually meaningful in the current structure. Authentication methods (SSH keys, .netrc, passwords, etc.) are all replaced by account logins, so they are not subjects for individual examination.

Assessment Items

Example

Check Support

Description

Verify for each task whether it can be replaced with the INNORIX CLI. Tasks with ambiguous support status are marked as "Pending" and determined through actual measurements during the parallel operation phase.

Inspection Criteria

CLI Preparation

Description

Install the INNORIX CLI and create a session by logging in with an Exacoola account (email + password). Subsequent commands are authenticated using the saved session, so you do not need to include authentication information in individual commands.

Usage Options

Example

Installation:

# Linux (.deb / .rpm)
sudo dpkg -i innorix-cli_x.y.z_amd64.deb
innorix --version

Login — Creates a session by receiving the password interactively.

innorix login --endpoint exa.example.com:443 --email hyunmin@example.com
# Password: ******** ← Not saved in screen/shell history

Profile Registration — Only the server and email are saved; the password is not saved.

innorix profile add prod --endpoint exa.example.com:443 --email hyunmin@example.com

Process

1. After installing the package, check with innorix --version
2. Enter email and password interactively with innorix login → Create session (~/.innorix/session)
3. (Optional) Save reusable servers and accounts using innorix profile add

Device Assignment

Description

The target device is specified using the URI format exa://<device selector>/<path>. The device selector uses one of the following: device ID, IP, MAC address, or device name. Since the local PC executing the command automatically looks up the device ID by sending its MAC address to the server, there is no need to specify the local side; the device specified in the command is always the target (remote) device.

Usage Notation

• If the prefix is ​​omitted, it is interpreted as the device name. MAC addresses are separated by hyphens (-) instead of colons (:) to avoid URI notation conflicts.
• The login target server (--endpoint, including port) and the transfer target device (exa://<device>) are separate.
• Compatible subcommands (scp/rsync, etc.) accept the legacy colon notation <device>:/path instead of exa:// for portability (the device identifier replaces user@host in scp, ignoring the old user@). In this case, only the identifier without a prefix is ​​used.

Command Switching

The INNORIX CLI provides two types of commands. The native transfer innorix <source> <destination> determines the direction based on the source and destination locations without a verb (local to remote upload, remote to local download, remote to remote transfer), while the compatible subcommands innorix ftp, sftp, scp, and rsync accept the flags and arguments of existing tools as they are to port existing scripts with minimal modification. Non-transfer tasks are performed using the reserved keywords innorix ls, rm, mkdir, login, and profile.

FTP Conversion

Description

Only put and get are supported in FTP sessions. Specify the target device in place of ftp host (innorix ftp <device>), and remove the user line from the existing script, replacing it with the existing login session. Distinguishing between binary and ascii modes is unnecessary (always binary-safe transfer).

Example

# existing
ftp -n ftp.example.com <<'END'
user alice s3cret
binary
put report.pdf /incoming/report.pdf
bye
END

# INNORIX CLI — Device as an argument, put/get only
innorix ftp web-01 <<'END'
put report.pdf /incoming/report.pdf
get /incoming/result.csv ./result.csv
bye
END

Process

1. Start a session with innorix ftp <device> (use existing login session for authentication)
2. Transfer files using put/get
3. End session with bye

Switch to SFTP

Description

Open a session with innorix sftp <device> instead of sftp user@host. It supports both interactive and batch (-b) modes, and most of the put/get/ls/mkdir/rm syntax is reused as is.

Example

Interactive:

# existing
sftp alice@sftp.example.com

# INNORIX CLI
innorix sftp web-01
innorix> put archive.zip /data/archive.zip
innorix> get /data/result.csv ./result.csv
innorix> bye

Placement (Non-conversation):

# existing
sftp -b commands.txt alice@sftp.example.com

# INNORIX CLI
innorix sftp web-01 -b commands.txt

Process

1. Start a session with innorix sftp <device> (or run a batch file with -b)
2. Send using existing syntax such as put/get
3. End Session

SCP Transformation

Description

scp uses the legacy colon notation <device>:/path. Only the device identifier (device ID, IP, name; MAC is hyphenated) is entered in place of user@host in scp, and the old user@ is ignored. The -r (recursive) function remains the same, and the connection port is specified to the server endpoint during login rather than the device path.

Example

# Existing — Upload
scp report.pdf alice@host.example.com:/incoming/
# INNORIX CLI — Replace host with device ID
innorix scp report.pdf DEV-1024:/incoming/

# Existing — Recursive directory download
scp -r alice@host.example.com:/data/logs ./logs
# INNORIX CLI
innorix scp -r DEV-1024:/data/logs ./logs

Process

1. Replace the user@host token in the original command with the device identifier.
2. Existing flags such as -r are retained.
3. Execution → Authenticate via existing login session and send

rsync switch

Description

rsync also uses the colon notation <device>:/path. Frequently used options such as -a (recursive), --exclude, --bwlimit, and --partial are retained, but flags not handled by the INNORIX CLI, such as -v, -z, -C, and -p, are removed. Deleting mirrors (--delete) is currently not supported. The slash ending rule remains the same as rsync (the presence or absence of a trailing / determines "copy contents vs. copy directory").

Example

# Existing — Compression + Progress
rsync -avz --progress ./site/ alice@host.example.com:/var/www/site/
# INNORIX CLI (v/z/C/p etc. omitted)
innorix rsync -a --progress ./site/ web-01:/var/www/site/

# Exclusion Pattern + Bandwidth Limit + Resume
rsync -a --exclude='*.tmp' --bwlimit=5000 --partial ./data/ host:/dest/
innorix rsync -a --exclude='*.tmp' --bwlimit=5000 --partial ./data/ web-01:/dest/

Process

1. Replace the user@host token with the device identifier.
2. Remove unsupported flags such as -v, -z, and -p, and keep the rest.
3. Execute

Direct transfer between devices

Description

If you specify remote devices for both the source and destination, direct transfer between devices occurs automatically—data moves directly between the two devices without passing through the local network. It uses the native transfer primitive, and appends --remote-to-remote only when explicitly enforcing the intent.

Example

# Existing — SCP copy between remote (via local)
scp -r alice@hostA:/data/ bob@hostB:/data/

# INNORIX CLI — Direct transfer bypassing local
innorix exa://siteA/data/ exa://siteB/data/

# Explicitly enforce
innorix --remote-to-remote exa://siteA/data/ exa://siteB/data/

Process

1. Set both source and target to exa://<device>/...
2. Automatically perform transfer between local non-intermediary devices
3. (Optional) Explicitly enforce with --remote-to-remote

Encrypted transfer

Description

Whether to encrypt the transfer path is specified by the global option --encrypt <true|false>, which applies to all commands (default is true if not specified). There is no dedicated subcommand, and false is considered only when performance is prioritized within a trusted private network.

Usage Options

Example

innorix --encrypt true ./logs exa://web-01/data/logs
innorix --encrypt false ./bulk/ exa://web-01/staging/

Option Mapping

Description

This is the correspondence between existing options and INNORIX CLI options. "Identical" means using the same flags as they are.

Common / SCP·rsync Options

Remove on switch: -v(verbose), -z/-C(compress), -p(preserve privileges), -P 2222(port). Replace port with server endpoint(--endpoint) and verbose output with --log-level.

INNORIX CLI Global Options

Script Switching

Once command-level switching is complete, replace only the calls in the wrapping script. Maintain exit code branching, output parsing, and non-interactive execution policies as they are, but verify them in accordance with the INNORIX CLI specifications.

Shell Script

Description

Replace only the calling part and maintain the rest of the logic. Check exit code ($?) branching, grep/awk output parsing, and suppress confirmation prompts (-y/--yes).

Example

#!/usr/bin/env bash
set -euo pipefail

# Existing: rsync -avz ./out/ alice@host:/var/www/out/
innorix rsync -a ./out/ web-01:/var/www/out/

Process

1. Replace the transfer call part with innorix ...
2. Verify that the exit code and output parsing logic are maintained.
3. Specify non-interactive execution options

Batch · PowerShell

Description

For Windows Batch and PowerShell, replace only the calling part. Pay particular attention to path separators (\ vs /) and Korean filename encoding (console code page UTF-8).

Example

Batch(.bat/.cmd):

REM Existing: winscp.com ... "put file.zip /data/"
innorix scp file.zip web-01:/data/
if %ERRORLEVEL% NEQ 0 ( echo Transfer failed & exit /b 1 )

PowerShell:

innorix scp .\report.pdf web-01:/incoming/
if ($LASTEXITCODE -ne 0) { Write-Error "Transfer failed"; exit 1 }

Scheduled Tasks

Description

Since cron, systemd timers, and task schedulers do not have interactive sessions, the transfer is run after a non-interactive login in the wrapper script. Login information is injected into environment variables or a file with narrowed permissions.

Example

cron:

# Existing: 0 2 * * * rsync -az /data/ host:/backup/ ...
0 2 * * *  /opt/innorix/nightly-sync.sh >> /var/log/innorix-sync.log 2>&1

Wrapper script:

#!/usr/bin/env bash
set -euo pipefail
export INNORIX_EMAIL="svc-batch@example.com"
export INNORIX_PASSWORD="$(cat /etc/innorix/secret)" # File permissions 600
innorix login
innorix rsync -a /data/ web-01:/backup/

Process

1. Inject batch-only account information into environment variables/files
2. Non-conversational login from the wrapper to innorix login
3. Execute transfer to session

Environment Variables

Description

For scripts and scheduled tasks that do not support interactive input, you can perform non-interactive login by receiving login information as an environment variable. Since passing the password directly as a command argument exposes it to the ps history, inject it into an environment variable or a file with narrowed permissions.

Variables Used

Example

export INNORIX_EMAIL="svc-batch@example.com"
export INNORIX_PASSWORD="$(cat /etc/innorix/secret)" # File permissions 600
innorix login
innorix rsync -a ./data/ web-01:/backup/

If possible, use a batch-only service account instead of a human account, inject passwords from a secret repository, and verify log masking.

Verification·Operation

We measure and verify the migrated work, operate it in parallel with existing tools to compare integrity, and then sequentially complete the migration.

Pre-validation

Description

We take measurements using non-operational data before the full migration.

Inspection Items

Integrity Comparison

Description

Verify that the transfer result is identical to the original. Compare the file count, total bytes, and individual checksums, and if there is a discrepancy, prioritize suspecting the encoding, symbolic links, and permission mapping.

Example

# Enable verification on transfer
innorix rsync -a --verify sha256 ./data/ web-01:/backup/

# Post-hoc check: Target checksum list
innorix ls --checksum sha256 exa://web-01/backup/ > remote.sha

Parallel Operation

Description

We run the existing tool and INNORIX CLI simultaneously for a certain period and compare the results.

Process

1. Execute the same operation on both sides, but place the INNORIX side in a separate target path and make a determination solely based on integrity comparison.
2. Only tasks judged as "Verification Complete" are exclusively switched
3. Record performance, error rate, and retry frequency

Errors · Rollback

Description

The converted operation saves the existing command, allowing it to be restored immediately.

Process

1. Save existing commands as comments or separate scripts to secure a rollback path.
2. Resume with --resume on failure, maintain automatic retries based on exit code.
3. Rollback and cause analysis in case of integrity comparison failure or performance degradation

Operation Migration and Monitoring

Description

We migration sequentially, starting with low-risk tasks, and continuously monitor operational stability after the migration.

Process

1. Migration one-off uploads and non-essential backups first, and migration essential large-volume tasks last.
2. Disable existing tool calls for migration completion tasks in the scheduler (not deleted → retain the possibility of rollback)
3. Collect success/failure rates, time taken, resumption frequency, and authentication errors in logs (adjust detail level with --log-level)

Quick Response Table