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. Azure Blob에서 사내 서버로 파일 전달하기

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

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

IT 엔지니어개발자
  • AI 학습 데이터와 모델 파일의 전체 흐름 자동화하기
  • AI 모델 파일을 여러 엣지 장비에 배포하기
  • 폐쇄망·망분리 환경에서 파일을 승인 반입·반출하기
  • 승인된 파일을 여러 지점에 동시에 배포하기
  • Azure Blob에서 사내 서버로 파일 전달하기
  • 데이터베이스 덤프, 백업, 아카이브 파일을 원격 보관처로 자동 전달하기
  • 지점·공장·엣지 장비의 파일을 중앙으로 수집하기
  • CI/CD 빌드 결과물을 여러 서버에 배포하기
  • 서로 다른 클라우드 스토리지 사이에서 파일 이동하기
  • 서로 다른 AWS 계정의 S3 버킷 사이에 파일 전송하기
  • 고객별 파일 작업 공간 제공하기
  • 고객에게 만료 조건이 있는 대용량 다운로드 링크 제공하기
  • 고객이 브라우저에서 대용량 파일을 업로드하게 하기
  • 고객 작업 공간으로 대용량 파일 직접 보내기
  • 데이터베이스 백업 파일을 오브젝트 스토리지에 보관하기
  • Datadog으로 파일 전송 실패와 복구 알림 받기
  • 웹, 앱, 업무 시스템에 파일 전송 기능 추가하기
  • 파일 도착 후 검증·변환·후속 작업 실행하기
  • NAS, 파일 서버의 대량 파일을 클라우드로 이전하기
  • FTP 배치 작업을 관리형 파일 흐름으로 전환하기
  • Google Cloud Storage에서 Amazon S3로 직접 전송하기
  • Grafana에서 파일 전송 상태 대시보드 만들기
  • 전송된 파일의 해시값으로 무결성 자동 검증하기
  • 새 파일이 생기면 지정한 곳으로 자동 전송하기
  • Kubernetes에서 오브젝트 스토리지로 결과 파일 보내기
  • Git 밖의 대용량 파일과 빌드 결과물 자동 전달하기
  • Git으로 관리하기 어려운 파일을 자동 전달하기
  • 분산 서버의 로그·진단 파일을 중앙으로 모으기
  • 미디어 원본과 처리 결과를 단계별로 자동 전달하기
  • 수신 파일을 Microsoft Defender로 검사하고 후속 처리하기
  • 여러 단계의 파일 전송을 하나의 흐름으로 자동화하기
  • 승인된 파일을 여러 팀·지점에 자동 배포하기
  • 협력사 파일을 업무 시스템으로 자동 분류하기
  • 협력사·공급망과 정기적으로 파일 교환하기
  • 매일·매주 반복되는 파일 전송 자동화하기
  • 네트워크 중단 후 파일 전송을 자동으로 재개하기
  • rsync 작업을 관리형 파일 흐름으로 전환하기
  • 정해진 시간에 반복 파일 전송 예약하기
  • 소프트웨어·펌웨어를 여러 장비에 배포하고 결과 확인하기
  • 소프트웨어 패키지를 여러 서버·지점에 배포하기
  • 팀 폴더의 변경 파일을 여러 장비에 자동 반영하기
  • 팀 업무 폴더를 여러 PC에 자동 반영하기
  • 여러 장비의 파일을 한곳에서 찾고 직접 전송하기
  • 웹사이트에 대용량 파일 업로드·다운로드 기능 추가하기
  • 채널을 구독해 새 파일을 자동으로 받기
  • Amazon S3에서 Azure Blob으로 직접 전송하기
  • Amazon S3에서 Cloudflare R2로 파일 이전하기
  • Amazon S3 파일을 Linux 서버로 자동 내려받기
  • SCP 셸 스크립트를 CLI 기반 전송으로 전환하기
  • SFTP 계정과 배치 전송을 중앙에서 관리하기
  • Slack·Teams에서 파일 전송을 실행하고 상태 알림 받기
  • Windows 폴더의 파일을 Amazon S3로 자동 업로드하기
  • Windows와 Linux 서버 사이에 파일을 직접 전송하기

시작하기#

기본 개념#

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 파일 확인 → 전송 대상 선택 → 사내 서버 저장 → 결과 확인까지 하나의 작업으로 이어갈 수 있습니다.


대상 폴더#

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으로 구성할 수도 있습니다.

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

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

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

전달 시점#

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

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

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

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

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

예를 들어 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 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 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의 전체 파일을 내려받는 대신 온프레미스 환경에서 실제로 필요한 파일만 선택적으로 전달할 수 있습니다.

후속 처리#

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

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

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

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

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

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

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

실행 확인#

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

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

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

각 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
                        │
                        ▼
                 서버 저장 결과 확인

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

재실행 후에는 새로운 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) — 프리픽스 지정
&nbsp;&nbsp;&nbsp;↓

전송 생성 → 종료 상태까지 대기
&nbsp;&nbsp;&nbsp;↓

온프레미스 서버 (onprem-01) — 지정 폴더에 파일 저장
&nbsp;&nbsp;&nbsp;↓

실패 파일만 재시도

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

이전승인된 파일을 여러 지점에 동시에 배포하기다음데이터베이스 덤프, 백업, 아카이브 파일을 원격 보관처로 자동 전달하기

이 페이지에서

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