INNORIX
전송 빌더전송 파인더개발자리소스고객사
무료 시작하기
INNORIX

LET FILES
MOVE THEMSELVES

INNORIX는 모든 시스템과 환경에서 파일 이동과 자동화를 제공하는 엔터프라이즈 파일 인프라 기업입니다.
5,000개 이상의 기업 및 공공기관에서 사용하고 있습니다.

시작하기

  • 필요한 전송 만들기
  • 필요한 전송 찾기

주요 전송

  • 팀 업무 폴더 동기화
  • 고객에게 대용량 파일 전송
  • 여러 시스템 파일 탐색
  • FTP·SFTP·SCP·rsync 전환
  • 앱에 파일 전송 추가
  • 웹 업로드·다운로드 적용
  • AI·데이터 워크플로 구축
  • 모든 전송 둘러보기→

개발자

  • 개발자 센터
  • 구현 예제
  • API 빠른 시작
  • 개발자 가이드
  • API 레퍼런스
  • GitHub

리소스

  • 리소스 센터
  • 제품 가이드
  • 외부 서비스 연동
  • 배포 및 관리
  • 도움말 센터

고객사

  • 정부
  • 공공부문
  • 제조
  • 엔지니어링
  • 금융
  • 유통
  • IT/통신
  • 미디어
  • 의료
  • 교육

플랜

  • 가격 및 플랜

회사

INNORIX 소개

Exabyter를 찾고 계신가요?

이제 INNORIX Platform에 통합되었습니다

기타 INNORIX 제품

Al.bert — 스마트 교통 AI

글로벌 오피스

  • 미국 뉴욕
  • 대한민국 서울
  • 베트남 호찌민
  • 오피스 위치 보기→

(C)2026 INNORIX. All rights reserved.

  • 보안
  • 상태
  • 이용약관
  • 개인정보 처리방침
  • 쿠키 정책
  1. 개발자
  2. 개발자 가이드
  3. Azure Blob에서 사내 서버로 파일 전달하기

Azure Blob에서 사내 서버로 파일 전달하기

Azure Blob의 파일을 사내 Windows 또는 Linux 서버의 지정 폴더로 전달합니다.

IT 엔지니어개발자
배포 및 관리
Exabyter
  • 개발자 가이드
  • AI 모델 파일을 여러 엣지 장비에 배포하기
  • Azure Blob에서 사내 서버로 파일 전달하기
  • CI/CD 빌드 결과물을 여러 서버에 배포하기
  • Datadog으로 파일 전송 실패와 복구 알림 받기
  • FTP 배치 작업을 관리형 파일 흐름으로 전환하기
  • Google Cloud Storage에서 Amazon S3로 직접 전송하기
  • Grafana에서 파일 전송 상태 대시보드 만들기
  • Kubernetes에서 오브젝트 스토리지로 결과 파일 보내기
  • Git으로 관리하기 어려운 파일을 자동 전달하기
  • 수신 파일을 Microsoft Defender로 검사하고 후속 처리하기
  • rsync 작업을 관리형 파일 흐름으로 전환하기

시작하기#

기본 개념#

Azure Blob의 파일을 사내 서버 작업 폴더로 직접 전송하기

Azure 환경에서 생성되거나 저장된 파일을 사내 시스템에서 활용해야 하는 경우가 있습니다.

예를 들어 클라우드에서 생성된 처리 결과를 내부 업무 서버로 가져오거나, Azure Blob에 저장된 백업 파일을 사내 보관 서버에 전달할 수 있습니다.

기존에는 다음과 같이 담당자나 중간 환경을 통해 파일을 이동할 수 있습니다.

Azure Blob Storage
        │
        │ Download
        ▼
   Local PC / Server
        │
        │ Copy
        ▼
 On-Premises Server

직접 전송을 구성하면 Azure Blob과 온프레미스 서버를 하나의 파일 전송 흐름으로 연결할 수 있습니다.

┌─────────────────────┐
│  Azure Blob Storage │
│                     │
│   Source Container  │
└──────────┬──────────┘
           │
           │ File Transfer
           ▼
┌─────────────────────┐
│ On-Premises Server  │
│                     │
│  Windows / Linux    │
└─────────────────────┘

azure-blob-to-on-premises_1

이렇게 하면 Azure Blob 파일 확인 → 전송 대상 선택 → 사내 서버 저장 → 결과 확인까지 하나의 작업으로 이어갈 수 있습니다.


대상 폴더#

Azure의 파일 경로와 서버의 실제 작업 폴더 연결하기

Azure Blob의 하나의 Container에는 여러 업무와 서비스에서 사용하는 파일이 함께 저장될 수 있습니다.

따라서 Container 전체를 서버로 내려받기보다, 실제 온프레미스 환경에서 필요한 파일 경로만 선택해 전달할 수 있습니다.

예를 들어 Azure Blob에 다음과 같은 파일 구조가 있다고 가정합니다.

processing-container
│
├── completed/
│   ├── report/
│   │   ├── report-01.csv
│   │   └── report-02.csv
│   │
│   └── media/
│
├── backup/
│
└── temporary/

이 중 완료된 보고서 파일만 사내 서버의 업무 폴더로 전달할 수 있습니다.

Azure Blob Storage                    On-Premises Server

processing-container                  D:\data\incoming\
│                                     │
├── completed/                        ├── report-01.csv
│   └── report/       ───────────▶    └── report-02.csv
│       Selected
│
├── backup/        Not Included
└── temporary/     Not Included

Linux 서버를 사용하는 경우에는 /data/incoming/과 같은 지정 경로를 Target으로 구성할 수도 있습니다.

azure-blob-to-on-premises_2

전송 경로는 서버의 실제 업무 구조에 맞춰 구성할 수 있습니다.

구분 Source Target
저장 환경 Azure Blob Storage Windows 또는 Linux 서버
파일 위치 Container / Blob 경로 서버의 지정 폴더
파일 범위 지정된 경로 또는 파일 업무별 저장 위치
파일 선택 이름·확장자·경로 조건 지정 경로에 저장
활용 목적 클라우드 결과·백업·자료 내부 처리·업무·보관

이를 통해 Azure에 저장된 파일과 실제 사내 업무가 진행되는 서버 폴더를 직접 연결할 수 있습니다.

전달 시점#

필요할 때 실행하거나 파일 생성과 일정에 맞춰 자동 전달하기

Azure Blob의 파일을 사내 서버로 전달하는 작업은 일회성 다운로드로만 구성할 필요가 없습니다.

파일이 Azure에 생성된 이후 자동으로 전달하거나, 사내 업무가 시작되기 전에 정해진 시간에 필요한 파일을 서버로 가져오도록 구성할 수 있습니다.

예를 들어 다음과 같은 방식으로 활용할 수 있습니다.

전달 목적 구성 방식
처리 결과 수집 완료된 파일을 서버로 전달
정기 자료 반영 지정된 시간에 반복 실행
신규 파일 수집 새 파일을 확인해 자동 전달
변경 파일 반영 변경된 파일만 다시 전송
후속 처리 연결 파일 저장 후 다음 작업 실행

azure-blob-to-on-premises_3

예를 들어 Azure에서 야간 처리된 결과 파일을 매일 오전 사내 서버로 전달하는 경우 다음과 같이 구성할 수 있습니다.

Azure 처리 완료
        │
        ▼
결과 파일 확인
        │
        ▼
전송 조건 확인
        │
        ▼
사내 서버 전달
        │
        ▼
작업 폴더 반영

이후 서버에 파일이 저장되면 해당 파일을 사용하는 배치 작업이나 분석 프로그램을 자동으로 실행하도록 연결할 수도 있습니다.

IT 엔지니어#

환경 연결#

Azure Blob Storage와 사내 서버를 각각 전송 환경에 등록하기

먼저 파일을 가져올 Azure Blob Storage와 파일을 저장할 온프레미스 서버를 각각 연결합니다.

Source와 Target은 서로 다른 환경이므로 파일 접근과 저장 범위를 분리해 관리할 수 있습니다.

Azure Blob에서는 전송할 Container와 파일을 읽을 수 있어야 하며, 사내 서버에서는 지정된 폴더에 파일을 저장할 수 있어야 합니다.

Transfer Environment

Azure Blob Storage
└── Source Container
    └── Read Files

        │
        ▼

Transfer Flow

        │
        ▼

Windows / Linux Server
└── Target Folder
    └── Write Files

azure-blob-to-on-premises_4

전송을 구성하기 전에 다음 항목을 확인합니다.

연결 환경 확인 내용
Azure Blob Source Container 접근 상태
Source 경로 전송할 파일과 경로 읽기
온프레미스 서버 Target 장비 연결 상태
대상 폴더 실제 파일 저장 위치
서버 권한 파일 생성 및 저장 가능 여부
네트워크 클라우드와 서버 간 연결 상태

각 환경을 독립적으로 연결하면 Azure의 Storage 접근 범위와 사내 서버의 파일 저장 범위를 분리하면서 하나의 전송 작업으로 연결할 수 있습니다.

경로 구성#

Container의 파일 위치를 서버의 업무 폴더에 맞춰 매핑하기

연결 환경을 준비한 뒤에는 Azure Blob에서 파일을 가져올 위치와 사내 서버에서 파일을 저장할 위치를 설정합니다.

예를 들어 Azure Blob의 다음 경로를 Source로 지정할 수 있습니다.

processing-container/completed/report/

Windows 서버에서는 다음과 같이 Target 폴더를 지정할 수 있습니다.

D:\data\incoming\report\

Linux 서버에서는 다음과 같이 구성할 수 있습니다.

/data/incoming/report/

전체 전송 구조는 다음과 같이 구성됩니다.

Source

Azure Blob Storage
processing-container
└── completed/
    └── report/
        ├── report-01.csv
        ├── report-02.csv
        └── report-03.csv

                │
                │ Transfer
                ▼

Target

Windows / Linux Server
└── Target Folder
    ├── report-01.csv
    ├── report-02.csv
    └── report-03.csv

azure-blob-to-on-premises_5

업무에 따라 하나의 Azure Container에서 여러 서버로 파일을 분기하거나, 여러 Azure 경로의 파일을 하나의 중앙 서버로 수집하는 방식으로 확장할 수도 있습니다.

예를 들어 파일 유형에 따라 서로 다른 내부 서버로 전달하면 다음과 같은 구성이 가능합니다.

                    ┌──▶ Windows Server
                    │     D:\report\
Azure Blob ── Flow ─┼──▶ Linux Server
                    │     /data/media/
                    │
                    └──▶ Archive Server
                          /backup/

이처럼 Azure Blob의 하나의 파일 저장 환경을 시작점으로 두고, 사내 업무 구조에 맞춰 여러 온프레미스 환경으로 파일을 전달할 수 있습니다.

파일 조건#

서버에서 필요한 파일만 선택해 지정된 위치로 전달하기

Azure Blob에는 처리 중인 파일과 완료된 파일, 백업 파일 등이 함께 저장될 수 있습니다.

따라서 모든 Blob을 서버로 전달하기보다 파일 이름이나 확장자, 경로를 기준으로 실제 업무에 필요한 파일만 선택할 수 있습니다.

예를 들어 다음과 같이 구성할 수 있습니다.

파일 조건 전달 방식
completed/*.csv Windows 업무 서버로 전달
media/*.mp4 Linux 미디어 서버로 전달
backup/*.zip 내부 보관 서버로 전달
temporary/* 전송 대상에서 제외
변경된 파일 변경 파일만 다시 반영

azure-blob-to-on-premises_6

이렇게 하면 Azure Blob의 전체 파일을 내려받는 대신 온프레미스 환경에서 실제로 필요한 파일만 선택적으로 전달할 수 있습니다.

후속 처리#

서버 폴더에 파일이 저장된 후 다음 작업까지 자동으로 연결하기

Azure Blob의 파일이 사내 서버에 저장된 후에는 해당 파일을 사용하는 다음 작업을 연결할 수 있습니다.

예를 들어 보고서 파일이 Windows 서버에 저장되면 내부 프로그램에서 데이터를 처리하거나, Linux 서버의 작업 폴더에 미디어 파일이 도착하면 변환 작업을 시작하도록 구성할 수 있습니다.

Azure Blob
     │
     ▼
File Transfer
     │
     ▼
On-Premises Folder
     │
     ├──────────────▶ Application
     │
     ├──────────────▶ Next Flow
     │
     └──────────────▶ Completion Notice

azure-blob-to-on-premises_7

후속 작업은 파일이 Target에 정상적으로 반영된 결과를 기준으로 실행할 수 있습니다.

연결 대상 활용 방식
내부 프로그램 전달된 파일을 서버에서 바로 처리
다음 Flow 다른 서버나 Storage로 파일 전달
업무 알림 파일 도착과 처리 결과 알림
운영 환경 전송 상태와 처리 결과 확인

이를 통해 클라우드 파일 전달 → 서버 폴더 반영 → 내부 처리 → 결과 확인까지 하나의 업무 흐름으로 연결할 수 있습니다.

실행 확인#

클라우드의 원본 파일과 서버의 저장 결과를 함께 확인하기

전송 작업이 실행되면 Runs에서 전체 처리 상태와 실행 결과를 확인할 수 있습니다.

특정 Run을 선택하면 Azure Blob의 Source와 온프레미스 서버의 Target, 전송 파일 수와 전체 용량, 진행 상태를 확인할 수 있습니다.

azure-blob-to-on-premises_8

각 Run에서는 다음 정보를 확인할 수 있습니다.

확인 항목 확인 내용
Source Azure Blob Container와 원본 경로
Target Windows 또는 Linux 서버와 대상 폴더
Total Files 전체 전송 파일 수
Total Size 전체 전송 용량
Progress 현재 전송 진행률
Status 완료·진행·실패 상태
Started 전송 시작 시간
Completed 전송 완료 시간

전송이 완료되면 전체 Run 상태와 함께 실제 Target 서버의 지정 폴더에 파일이 정상적으로 저장되었는지 확인할 수 있습니다.

이를 통해 어떤 Azure 파일이 어느 사내 서버로 전달되었는지와 최종 저장 결과를 하나의 실행 기록을 기준으로 관리할 수 있습니다.

문제 대응#

Azure Source와 온프레미스 Target을 구분해 원인을 확인하기

전송 중 추가 확인이 필요한 상황이 발생하면 먼저 Azure Blob과 온프레미스 서버 중 어느 환경에서 문제가 발생했는지 구분합니다.

Azure Blob에서 파일을 읽을 수 없는 경우에는 Storage 연결 상태와 Container, 파일 경로를 확인합니다. 반대로 서버에 파일을 저장할 수 없는 경우에는 Target 장비 연결과 대상 폴더, 저장 권한을 확인합니다.

                 Transfer Failed
                        │
           ┌────────────┴────────────┐
           │                         │
           ▼                         ▼
      Azure 확인                 Server 확인
           │                         │
    Container 연결               장비 연결 상태
    Source 파일 경로             Target 폴더
    파일 읽기 권한               파일 저장 권한
           │                         │
           └────────────┬────────────┘
                        ▼
                    환경 조정
                        │
                        ▼
                      Retry
                        │
                        ▼
                 서버 저장 결과 확인

azure-blob-to-on-premises_9

문제를 확인한 뒤 필요한 연결이나 경로, 접근 범위를 조정하고 작업을 다시 실행할 수 있습니다.

재실행 후에는 새로운 Run을 통해 Azure Blob의 파일이 사내 Windows 또는 Linux 서버의 지정된 작업 폴더에 정상적으로 반영되었는지 확인합니다.

이 레시피를 적용하면 Azure Blob 연결 → Source 파일과 경로 선택 → Windows 또는 Linux 서버 Target 구성 → 파일 조건과 실행 시점 설정 → 클라우드에서 온프레미스로 직접 전송 → 서버 반영 후 후속 작업 연결 → Run 결과 확인 → 저장 결과 검증까지 하나의 흐름으로 구성할 수 있습니다.

이를 통해 클라우드에 저장된 파일을 중간 PC를 거치지 않고 사내 업무 환경으로 직접 전달하고, 서버의 실제 작업 폴더에서 파일 활용과 후속 처리까지 이어지는 하이브리드 파일 전송 환경을 구성할 수 있습니다.

개발자#

Azure Blob 파일을 온프레미스 서버로 전송하고 결과를 확인하기

소스(Azure Blob)와 대상(서버)을 각각 장비로 등록한 뒤, 프리픽스와 서버 경로를 지정해 전송을 만들고 종료 상태를 확인합니다. 시작 전에 다음 항목을 준비합니다.

준비물 내용
INNORIX 인증 INNORIX_ACCESS_TOKEN (Authorization: Bearer)
소스 Azure 장비 Azure Blob 컨테이너의 device ID와 원본 프리픽스 (예: export/2026/09)
대상 서버 장비 사내 서버의 device ID와 저장 폴더 경로 (예: /data/incoming)
런타임 Python 3 + requests · Java 17+ · Node.js 18+ · .NET 8+

Python·Node.js는 REST를 직접 호출하는 최소 api() 헬퍼와 상태 상수(STATUS_COMPLETE·TERMINAL)를 API 호출 레시피의 것을 재사용합니다. Java·C#은 번들 소스의 InnorixClient(상수 포함)와 Json(C#은 J) 헬퍼를 사용합니다. 장비 식별자(azure-src·onprem-01)와 경로는 실제 값으로 바꿔 넣습니다.

Azure Blob → 서버 전송 생성#

Azure Blob의 프리픽스를 폴더 루트로 넣고(sourcePaths + sendAllFolder), 서버의 절대 경로를 targetPath로 지정합니다. 전송 생성 후 monitorId로 종료 상태를 확인합니다.

import time


def transfer_to_server(source, target, prefixes, target_path, action="overwrite"):
    transfer = api("POST", "/api/transfers/manual", {
        "sourceDevice": source,
        "targetDevice": target,
        "targetPath": target_path,
        "sourcePaths": prefixes,
        "sendAllFolder": True,
        "transferOptions": {"target-action": action},
    })
    return transfer["monitorId"]


def wait_transfer(monitor_id, timeout=14400, interval=5):
    deadline = time.time() + timeout
    while time.time() < deadline:
        detail = api("GET", f"/api/transfers/{monitor_id}") or {}
        if detail.get("status") in TERMINAL:
            return detail
        time.sleep(interval)
    raise TimeoutError(monitor_id)


monitor_id = transfer_to_server("azure-src", "onprem-01", ["export/2026/09"], "/data/incoming")
detail = wait_transfer(monitor_id)
print("completed:", detail.get("status") == STATUS_COMPLETE)
static String transferToServer(InnorixClient client, String source, String target,
        List<String> prefixes, String targetPath, String action) {
    Map<String, Object> transfer = client.apiObj("POST", "/api/transfers/manual", Json.newObj(
            "sourceDevice", source,
            "targetDevice", target,
            "targetPath", targetPath,
            "sourcePaths", prefixes,
            "sendAllFolder", true,
            "transferOptions", Json.newObj("target-action", action)), null);
    return Json.str(transfer, "monitorId");
}

static Map<String, Object> waitTransfer(InnorixClient client, String monitorId,
        long timeoutSec, long intervalSec) throws InterruptedException {
    long deadline = System.currentTimeMillis() + timeoutSec * 1000;
    while (System.currentTimeMillis() < deadline) {
        Map<String, Object> detail = client.apiObj("GET", "/api/transfers/" + monitorId, null, null);
        Integer status = Json.intOrNull(detail, "status");
        if (status != null && InnorixClient.TERMINAL.contains(status))
            return detail;
        Thread.sleep(intervalSec * 1000);
    }
    throw new RuntimeException("timeout: " + monitorId);
}
async function transferToServer(source, target, prefixes, targetPath, action = "overwrite") {
  const transfer = await api("POST", "/api/transfers/manual", {
    sourceDevice: source,
    targetDevice: target,
    targetPath,
    sourcePaths: prefixes,
    sendAllFolder: true,
    transferOptions: { "target-action": action },
  });
  return transfer.monitorId;
}

async function waitTransfer(monitorId, { timeout = 14400, interval = 5 } = {}) {
  const deadline = Date.now() + timeout * 1000;
  while (Date.now() < deadline) {
    const detail = (await api("GET", `/api/transfers/${monitorId}`)) || {};
    if (TERMINAL.has(detail.status)) return detail;
    await new Promise((r) => setTimeout(r, interval * 1000));
  }
  throw new Error(`timeout: ${monitorId}`);
}

const monitorId = await transferToServer("azure-src", "onprem-01", ["export/2026/09"], "/data/incoming");
const detail = await waitTransfer(monitorId);
console.log("completed:", detail.status === STATUS_COMPLETE);
static async Task<string> TransferToServerAsync(InnorixClient client, string source, string target,
    IEnumerable<string> prefixes, string targetPath, string action = "overwrite")
{
    var transfer = await client.ApiObjAsync("POST", "/api/transfers/manual", new JsonObject
    {
        ["sourceDevice"] = source,
        ["targetDevice"] = target,
        ["targetPath"] = targetPath,
        ["sourcePaths"] = J.ArrOfStrings(prefixes),
        ["sendAllFolder"] = true,
        ["transferOptions"] = new JsonObject { ["target-action"] = action },
    });
    return J.Str(transfer, "monitorId");
}

static async Task<JsonObject> WaitTransferAsync(InnorixClient client, string monitorId,
    int timeoutSec = 14400, int intervalSec = 5)
{
    DateTime deadline = DateTime.UtcNow.AddSeconds(timeoutSec);
    while (DateTime.UtcNow < deadline)
    {
        JsonObject detail = await client.ApiObjAsync("GET", 
quot;/api/transfers/{monitorId}"
, null, null); int? status = J.IntOrNull(detail, "status"); if (status != null && InnorixClient.Terminal.Contains(status.Value)) return detail; await Task.Delay(intervalSec * 1000); } throw new TimeoutException(monitorId); }

서버 경로는 절대 경로 targetPath는 대상 서버의 절대 경로로 지정합니다(Windows는 C:/share/incoming, Linux는 /data/incoming). 대상 폴더가 없으면 전송이 실패할 수 있으므로 미리 준비합니다.

정기 반입 같은 프리픽스를 주기적으로 반입해야 하면 예약 자동화(S3→Linux 자동 다운로드 레시피 참고)로 전환해 정해진 시각마다 실행할 수 있습니다.

실패 파일이 남으면 중단 후 재개 레시피의 retry_failed로 실패분만 다시 전송합니다.

구현 결과#

이 레시피를 적용하면 다음 흐름으로 Azure Blob 파일을 온프레미스 서버로 전달할 수 있습니다.

Azure Blob (azure-src) — 프리픽스 지정
   ↓
전송 생성 → 종료 상태까지 대기
   ↓
온프레미스 서버 (onprem-01) — 지정 폴더에 파일 저장
   ↓
실패 파일만 재시도

클라우드 자격 증명을 코드에서 다루지 않고 device ID와 경로만으로 Azure Blob → 서버 전송을 실행하며, 남은 실패 파일만 선택해 다시 보낼 수 있습니다.

이전AI 모델 파일을 여러 엣지 장비에 배포하기다음CI/CD 빌드 결과물을 여러 서버에 배포하기

이 페이지에서

  • 시작하기
  • 기본 개념
  • 대상 폴더
  • 전달 시점
  • IT 엔지니어
  • 환경 연결
  • 경로 구성
  • 파일 조건
  • 후속 처리
  • 실행 확인
  • 문제 대응
  • 개발자
  • Azure Blob → 서버 전송 생성
  • 구현 결과