Tự động hóa Upload lên Render Farm bằng Python: Hướng dẫn paramiko và rsync

Phần chậm nhất trong quá trình cloud render thường không phải là bản thân quá trình render. Đối với một studio đang đẩy shot VFX đa camera hay Houdini cache 400 GB lên farm mỗi đêm, nút cổ chai chính là việc di chuyển dữ liệu — đưa dự án lên một cách đáng tin cậy, và kéo các frame đã hoàn thành về trước khi mọi người đến làm buổi sáng. Làm thủ công, ngồi nhìn thanh tiến trình lúc nửa đêm, không thể mở rộng quy mô được. Dùng script thì có thể.

Hướng dẫn này nói về việc tự động hóa lớp truyền file đó bằng Python. Chúng tôi vận hành Super Renders Farm, một render farm quản lý toàn diện, và "quản lý toàn diện" có nghĩa cụ thể đối với automation: bạn không remote vào máy, không cài phần mềm, không quản lý license — vì vậy phần pipeline mà bạn viết script chính là phần bạn sở hữu — các file đi lên và các frame render đi xuống. Bề mặt truyền file hoàn toàn có thể script hóa qua SFTP, và Python là lựa chọn hàng đầu để thực hiện điều đó. Tài liệu truyền file của chúng tôi trực tiếp đề cập thư viện paramiko của Python như một client được hỗ trợ, cùng với rsync qua SSH và lệnh sftp tiêu chuẩn.

Chúng tôi cũng sẽ nói thẳng về những gì bạn không thể tự động hóa từ Python hiện nay, bởi vì một pipeline được xây dựng trên một tính năng chưa tồn tại là một pipeline sẽ thất bại trong lần chạy unattended đầu tiên. Nếu bạn muốn bản đồ khái niệm tổng thể — "headless" khác "unattended" như thế nào, cách chuẩn bị scene cho command-line rendering — đó là một hướng dẫn đồng hành khác. Hướng dẫn này ở mức code, tập trung vào lớp truyền file: paramiko, rsync, SSH key, retry, và pattern đồng bộ hàng đêm mà bạn có thể đặt vào automation của studio.

Những gì bạn có thể tự động hóa bằng Python hiện nay

Việc xác định ranh giới trước khi viết bất kỳ code nào rất hữu ích. Trên một render farm được quản lý, một số phần của pipeline hoàn toàn có thể script hóa, một số chủ đích dùng GUI, và một phần nằm ở giữa. Hiểu rõ phần nào là phần nào sẽ giúp automation của bạn không bị hỏng âm thầm.

Ma trận diagram cho thấy bước nào trong pipeline render farm có thể tự động hóa bằng Python trên managed cloud render farm: Upload project (hoàn toàn có thể script qua paramiko, rsync, sftp), Download output (hoàn toàn có thể script), Phát hiện job hoàn thành (một phần — poll thư mục output SFTP, không có status API), Submit render job (chỉ GUI — web form, Client App, hoặc DCC plugin), Quản lý tài khoản và thanh toán (chỉ GUI), với cột trạng thái xanh, hổ phách và xám

• Upload dự án — hoàn toàn có thể script. SFTP từ paramiko, rsync, hoặc lệnh sftp đều hoạt động với SFTP server của chúng tôi. Đây là cốt lõi của những gì trình bày dưới đây.
• Tải về frame đã hoàn thành — hoàn toàn có thể script. Output nằm trong thư mục theo từng job mà bạn có thể kéo về bằng những công cụ tương tự.
• Phát hiện job đã hoàn thành — một phần. Không có public status API để poll. Những gì bạn có thể làm là poll thư mục output SFTP và theo dõi các frame xuất hiện và ổn định. Đây là heuristic, không phải tín hiệu chính thức, và chúng tôi xử lý như vậy bên dưới.
• Submit render job — chỉ GUI hiện tại. Submission chạy qua web form, SuperRenders Client App, hoặc DCC submission plugin. Một public REST API cho job submission, status polling và output retrieval đang trong lộ trình phát triển, nhưng hiện tại không có public API endpoint nào khả dụng để tích hợp trực tiếp. Nếu pipeline của bạn bị tắc nghẽn cụ thể vì submission API, hãy liên hệ support và chia sẻ use case — lộ trình được định hướng bởi yêu cầu pipeline thực tế.
• Quản lý tài khoản, credits hoặc thanh toán — GUI. Ngoài phạm vi của transfer automation.

Vậy bề mặt có thể tự động hóa là transfer: đẩy dự án lên, kéo render về, và lấp khoảng cách ở giữa bằng cách theo dõi thư mục output. Bước submission vẫn là bàn giao thủ công có chủ đích, và chúng tôi sẽ đánh dấu rõ ràng trong pipeline cuối cùng thay vì giả vờ nó không tồn tại. Để xem toàn cảnh về những gì managed rendering công khai và không công khai, hướng dẫn về render farm quản lý toàn diện là gì bao quát mô hình này; tài khoản mới có thể bắt đầu từ hướng dẫn getting started.

Điều kiện tiên quyết: Truy cập SFTP, SSH key, và môi trường Python

Ba thứ cần được chuẩn bị trước lần upload được script đầu tiên.

Truy cập SFTP, được kích hoạt theo từng tài khoản. SFTP được kích hoạt theo yêu cầu trên từng tài khoản. Đăng nhập, tìm "SFTP access" trong cài đặt tài khoản, và tạo credentials tại đó; nếu không thấy, hãy yêu cầu support kích hoạt. Credentials của bạn bao gồm hostname server (thay đổi theo region và storage allocation, nên đọc từ config, không bao giờ hard-code), username gắn với tài khoản, password hoặc SSH key, và SFTP port 22 tiêu chuẩn. Hai đường dẫn quan trọng: /uploads/<your-project-folder>/ là vùng ghi của bạn, và /output/<job-id>/ là nơi các render đã hoàn thành xuất hiện.

SSH key, không phải password. Đối với bất kỳ thứ gì tự động, xác thực SSH key là lựa chọn đúng — nó giữ bí mật ngoài script và hoạt động trong các lần chạy unattended mà không cần interactive prompt. Tạo một cặp key hiện đại và đăng ký phần public trên tài khoản của bạn:

ssh-keygen -t ed25519 -C "pipeline@yourstudio.example"
# add the contents of ~/.ssh/id_ed25519.pub in
# superrendersfarm.com -> Settings -> SFTP -> SSH Keys

Lưu ý về bảo mật tài khoản: xác thực hai yếu tố hiện chưa được hỗ trợ trên tài khoản, vì vậy với SFTP, biện pháp bảo mật mạnh nhất là passphrase trên file key cộng với SSH agent giữ key đã mở khóa cho session. Key, cộng với kiến thức về passphrase của nó, đóng vai trò tương tự như yếu tố thứ hai — sở hữu và bí mật.

Môi trường Python với paramiko. Mọi thứ bên dưới đều dùng paramiko, thư viện SSH/SFTP pure-Python tiêu chuẩn, và gọi shell ra rsync cho các transfer lớn cần tính incremental.

python3 -m venv .venv && source .venv/bin/activate
pip install paramiko

Diagram cấu trúc tài khoản SFTP và xác thực dựa trên key cho managed render farm: máy pipeline cục bộ giữ ed25519 private key kết nối qua SSH port 22 đến SFTP server của farm, công khai hai thư mục — /uploads/<project>/ làm vùng ghi cho project đến và /output/<job-id>/ làm vùng đọc cho các frame đã hoàn thành; public key tương ứng được đăng ký trong account settings

Đóng gói dự án để vượt qua upload unattended

Hầu hết các render job thất bại không phải lỗi engine — đó là lỗ hổng đóng gói. Một scene render được trên máy trạm của họa sĩ lại thất bại trên worker mới vì texture path trỏ đến ổ đĩa cục bộ, hoặc sub-scene được tham chiếu chưa bao giờ được bundle. Automation khuếch đại điều này: upload unattended của package hỏng tạo ra lỗi unattended. Hai quy tắc giữ package sạch.

Đầu tiên, làm cho dự án tự chứa với relative path. Chạy lệnh collect-and-package của DCC (Archive, Collect Files, Save Project with Assets) để mọi texture, proxy và cache resolve tương đối so với project root. Thứ hai, chú ý định dạng archive nếu bạn nén trước khi upload: chúng tôi hỗ trợ tar, tar.gz và 7z, nhưng không phải .zip — hãy repack thành .tar.gz, hoặc bỏ qua việc archive hoàn toàn và để rsync transfer cây thư mục, thường là lựa chọn tốt hơn cho các dự án đang thay đổi liên tục. Về giới hạn thực tế, giữ một lần upload đơn lẻ dưới ~300 GB; trên mức đó, hãy dựa vào rsync với resume thay vì một transfer nguyên khối.

Upload dự án với paramiko

Building block đầu tiên là bộ uploader đệ quy. Nó kết nối bằng key, duyệt cây dự án cục bộ, tái tạo cấu trúc thư mục dưới /uploads/, và put từng file. Chúng tôi pin host key với RejectPolicy và đọc thông tin kết nối từ environment để không có gì nhạy cảm nằm trong script.

import os
import paramiko

def connect():
    host = os.environ["SRF_SFTP_HOST"]
    user = os.environ["SRF_SFTP_USER"]
    key_path = os.environ["SRF_SFTP_KEY"]      # path to private key

    client = paramiko.SSHClient()
    client.load_system_host_keys()             # trust ~/.ssh/known_hosts only
    client.set_missing_host_key_policy(paramiko.RejectPolicy())
    client.connect(hostname=host, port=22, username=user, key_filename=key_path)
    return client, client.open_sftp()

def _ensure_remote_dir(sftp, remote_dir):
    # mkdir -p over SFTP: build the path one segment at a time
    path = ""
    for segment in remote_dir.strip("/").split("/"):
        path += "/" + segment
        try:
            sftp.stat(path)
        except IOError:
            sftp.mkdir(path)

def upload_dir(sftp, local_dir, remote_dir):
    for root, _dirs, files in os.walk(local_dir):
        rel = os.path.relpath(root, local_dir)
        remote_root = remote_dir if rel == "." else f"{remote_dir}/{rel.replace(os.sep, '/')}"
        _ensure_remote_dir(sftp, remote_root)
        for name in files:
            local_path = os.path.join(root, name)
            remote_path = f"{remote_root}/{name}"
            sftp.put(local_path, remote_path)
            print(f"uploaded {remote_path}")

Chạy nó cho một dự án:

client, sftp = connect()
try:
    upload_dir(sftp, "/local/projects/archviz-tower", "/uploads/archviz-tower-2026-06")
finally:
    sftp.close()
    client.close()

Đây đủ cho các dự án nhỏ và trung bình. sftp.put cũng chấp nhận tham số callback= nhận bytes-transferred và total, mà bạn có thể kết nối với progress meter hoặc log line cho mỗi file. Tuy nhiên, với các transfer lớn và lặp lại đặc trưng của công việc studio, rsync là công cụ tốt hơn.

Flow diagram của upload routine paramiko cho render farm: thư mục dự án cục bộ được duyệt file by file với os.walk, cây thư mục remote được tạo dưới /uploads với vòng lặp mkdir-p, sau đó mỗi file được gửi với sftp.put qua kết nối xác thực SSH key, với progress callback ghi log mỗi file hoàn thành

Đồng bộ incremental với rsync qua SSH

Một dự án render hiếm khi được upload một lần. Bạn chỉnh shader, re-cache sim, sửa đèn, và upload lại. Gửi toàn bộ thư mục mỗi lần tốn hàng giờ; rsync chỉ gửi những gì đã thay đổi. Đối với studio upload hàng đêm, đây là tiết kiệm thời gian lớn nhất trong lớp transfer, vì nó chỉ transfer delta thay vì toàn bộ dự án.

Lệnh gọi chuẩn:

rsync -avz --partial --progress \
  /local/projects/archviz-tower/ \
  "$SRF_SFTP_USER@$SRF_SFTP_HOST:/uploads/archviz-tower-2026-06/"

-a giữ nguyên cấu trúc và timestamp, -z nén trong quá trình truyền, --partial giữ lại các file đã transfer một phần để kết nối bị mất có thể resume thay vì restart, và --progress báo cáo theo từng file. Chạy lại lệnh tương tự sau khi thay đổi chỉ transfer các file đã sửa đổi. Vì mục tiêu là automation, hãy wrap nó trong Python để nó nằm trong cùng script với mọi thứ khác, và để bạn có thể phản ứng với exit code của nó:

import subprocess

def rsync_up(local_dir, remote_subdir):
    host = os.environ["SRF_SFTP_HOST"]
    user = os.environ["SRF_SFTP_USER"]
    dest = f"{user}@{host}:/uploads/{remote_subdir}/"
    cmd = ["rsync", "-avz", "--partial", "--progress",
           f"{local_dir.rstrip('/')}/", dest]
    subprocess.run(cmd, check=True)   # raises CalledProcessError on failure

Để chạy unattended, hãy lên lịch. Một studio mirror thư mục làm việc lên farm mỗi đêm lúc 1 giờ sáng chỉ cần một dòng cron:

0 1 * * *  cd /studio/pipeline && /usr/bin/python3 nightly_sync.py >> sync.log 2>&1

Để rsync qua SSH xác thực mà không cần prompt, hãy trỏ nó đến key với -e "ssh -i ~/.ssh/id_ed25519", hoặc để SSH agent giữ key đã mở khóa cho session.

Diagram so sánh trước-sau giữa re-upload toàn bộ với rsync incremental sync lên render farm: bên trái, mọi file trong dự án được gửi lại mỗi đêm; bên phải, rsync so sánh local và remote và chỉ transfer các file đã thay đổi (một shader đã sửa và một cache mới), với phần bulk không thay đổi được bỏ qua, minh họa transfer delta-only giúp upload studio hàng đêm nhanh chóng

Tự động tải về frame đã hoàn thành

Khi một job hoàn thành, các frame output được ghi vào /output/<job-id>/ trên SFTP server. Phía tải về phản chiếu phía upload — một get đệ quy với paramiko, hoặc rsync pull. Phiên bản paramiko duyệt thư mục remote và tái tạo cục bộ:

import stat

def download_dir(sftp, remote_dir, local_dir):
    os.makedirs(local_dir, exist_ok=True)
    for entry in sftp.listdir_attr(remote_dir):
        remote_path = f"{remote_dir}/{entry.filename}"
        local_path = os.path.join(local_dir, entry.filename)
        if stat.S_ISDIR(entry.st_mode):
            download_dir(sftp, remote_path, local_path)
        else:
            sftp.get(remote_path, local_path)
            print(f"downloaded {local_path}")

Với các output set lớn, rsync pull lại là lựa chọn hiệu quả và có thể resume hơn:

rsync -avz --progress \
  "$SRF_SFTP_USER@$SRF_SFTP_HOST:/output/<job-id>/" \
  /local/downloads/<job-id>/

Một chi tiết vận hành quan trọng với pipeline unattended: output render được lưu giữ trong 45 ngày sau khi job hoàn thành, sau đó tự động xóa. SFTP không kéo dài cửa sổ đó. Pattern an toàn là đồng bộ hàng đêm mirror output về archive cục bộ ngay khi nó xuất hiện, để thời gian lưu giữ không bao giờ là lý do bạn mất frame.

Phát hiện job hoàn thành khi không có status API

Đây là nơi ranh giới thành thật trở thành lựa chọn kỹ thuật cụ thể. Không có public endpoint để hỏi "job 12345 đã xong chưa?" — nhưng thư mục output tự nó có thể quan sát qua SFTP. Pattern thực dụng là poll /output/<job-id>/, đếm các file, và chờ số lượng đạt đến tổng frame dự kiến và giữ ổn định qua nhiều lần kiểm tra liên tiếp (để bạn không bắt đầu tải về trong khi đang ghi).

import time

def wait_for_output(sftp, output_dir, expected_frames, poll=120, stable_checks=2):
    last_count, stable = -1, 0
    while True:
        try:
            files = sftp.listdir(output_dir)
        except IOError:
            files = []                      # folder not created yet -> not started
        count = len(files)
        if count >= expected_frames and count == last_count:
            stable += 1
            if stable >= stable_checks:
                return files                # count met and steady -> treat as done
        else:
            stable = 0
        last_count = count
        time.sleep(poll)

Hãy nhìn nhận thực tế về điều này là gì. Các frame xuất hiện dần dần, vì vậy sự hiện diện đơn thuần không phải là hoàn thành; kiểm tra số lượng so với tổng dự kiến và xác nhận nó ổn định giữa các lần poll là điều làm cho nó đáng tin cậy đủ cho automation. Đây là directory heuristic, không phải cam kết chính thức. Khi public API ra mắt, toàn bộ hàm này thu gọn thành một lần gọi status — cho đến lúc đó, theo dõi thư mục output là cách có cơ sở để lấp khoảng cách, và nó không phụ thuộc vào bất kỳ thứ gì chưa tồn tại.

Sequence diagram về polling thư mục output SFTP để phát hiện hoàn thành render mà không có status API: script pipeline liên tục liệt kê /output/<job-id>/, so sánh số frame với tổng dự kiến, chờ đến khi số lượng đáp ứng mục tiêu và giữ ổn định qua hai lần kiểm tra liên tiếp, rồi tiến hành tải về — với trạng thái thư mục trống ban đầu được hiển thị là job-not-started

Kết hợp lại: pipeline transfer unattended

Các phần ghép thành một script hàng đêm đơn lẻ. Hình dạng là: đồng bộ dự án lên, bàn giao cho submission, chờ output xuất hiện và ổn định, kéo xuống, verify và archive. Bước submission là bàn giao GUI có chủ đích — trên managed farm bạn submit qua web form, Client App hoặc DCC submission plugin, và các DCC plugin có thể được điều khiển từ môi trường scripting riêng của ứng dụng host (MAXScript, Python bên trong DCC) khi submission nằm trong tool bạn đã script. Chúng tôi đánh dấu bước đó thành thật thay vì wrap nó trong hàm giả vờ API tồn tại.

def nightly_pipeline(project_dir, remote_subdir, job_id, expected_frames):
    client, sftp = connect()
    try:
        # with_retries() (defined in the next section) wraps the fragile network calls
        with_retries(lambda: rsync_up(project_dir, remote_subdir))    # 1. push delta up
        # 2. SUBMIT: GUI / Client App / DCC plugin -- not a public API (yet)
        files = wait_for_output(                                      # 3. watch output dir
            sftp, f"/output/{job_id}", expected_frames)
        with_retries(lambda:                                          # 4. pull finished frames
            download_dir(sftp, f"/output/{job_id}", f"/local/downloads/{job_id}"))
        print(f"job {job_id}: {len(files)} frames retrieved")
    finally:
        sftp.close()
        client.close()

Bước 1, 3 và 4 hoàn toàn tự động; bước 2 là bàn giao. Khi public submission API ra mắt, bước 2 và 3 trở thành API call và directory poll sẽ không còn dùng nữa. Kiến trúc không thay đổi — chỉ có submission và status leg chuyển từ GUI và heuristic sang endpoint.

Flow diagram đầu cuối của pipeline transfer render farm unattended được điều khiển từ Python: bước 1 rsync upload project delta lên /uploads, bước 2 là bàn giao GUI được đánh dấu rõ ràng nơi job được submit qua web form, Client App hoặc DCC plugin (không có public API), bước 3 poll /output/<job-id> cho đến khi frame hoàn thành và ổn định, bước 4 tải xuống và archive các frame đã hoàn thành cục bộ — với các bước tự động hiển thị màu cyan và bước submit thủ công hiển thị màu xám

Xử lý lỗi, retry và transfer có thể resume

Unattended có nghĩa là không ai theo dõi khi transfer gặp sự cố, vì vậy script phải tự phục hồi. Ba thói quen bao phủ hầu hết các lỗi.

Retry lỗi tạm thời với backoff. Mất mạng ngắn và ngắt kết nối thoáng qua là bình thường trong quá trình transfer dài. Wrap các lệnh gọi dễ lỗi — như nightly_pipeline làm ở trên — để một lần mất kết nối đơn không giết chết toàn bộ quá trình. Bắt các lỗi tạm thời cụ thể thay vì mọi thứ: SSHException của paramiko, họ OSError cho socket, và CalledProcessError cho rsync thất bại.

def with_retries(fn, attempts=3, backoff=5):
    transient = (paramiko.SSHException, OSError, subprocess.CalledProcessError)
    for i in range(1, attempts + 1):
        try:
            return fn()
        except transient:                  # retry SSH / network / rsync hiccups
            if i == attempts:
                raise
            time.sleep(backoff * i)        # back off: 5s, 10s, 15s

Dựa vào khả năng resume. rsync --partial đã resume các file bị ngắt, và chạy lại rsync là idempotent — nó chỉ gửi những gì còn thiếu — vì vậy một sync được retry là rẻ, không phải restart. Với transfer paramiko, retry cộng với re-walk đạt hiệu quả tương tự vì các file đã có mặt transfer gần như tức thì.

Xử lý lỗi host-key và kết nối một cách rõ ràng. Lỗi "host key verification failed" có nghĩa là key được cache trong ~/.ssh/known_hosts không còn khớp với key của server — thường xảy ra nhất sau lần rotate host-key hiếm gặp. Xóa dòng cũ mà lỗi chỉ ra và kết nối lại để chấp nhận key mới. Connection refused hoặc timeout thường có nghĩa là tường lửa studio đang chặn TCP 22 outbound; cho phép nó hoặc hỏi support về các lựa chọn thay thế. Và nếu throughput thấp hơn nhiều so với tốc độ link của bạn, overhead per-packet của SFTP là nguyên nhân trên các kết nối long-haul — lftp với parallel segment, hoặc nhiều SFTP session đồng thời, sẽ thu hồi phần lớn khoảng cách đó.

Tóm tắt: cái gì để tự động hóa, và như thế nào

Lớp transfer là phần của pipeline managed farm mà bạn sở hữu trong code, và Python bao phủ tất cả.

Tự động hóa upload, tự động hóa download, lấp khoảng cách ở giữa bằng cách theo dõi thư mục output, và giữ bàn giao submission rõ ràng. Điều đó tạo cho bạn một pipeline hàng đêm thành thật về các kết nối của mình và đáng tin cậy vì điều đó. Với các dự án nặng simulation lớn nơi độ tin cậy transfer quan trọng nhất — Houdini cache nhiều terabyte và tương tự — các pattern tương tự mở rộng trực tiếp trên Super Renders Farm; trang Houdini cloud render farm của chúng tôi bao phủ workload đó.

FAQ

Q: Thư viện Python nào nên dùng để upload lên render farm? A: paramiko là lựa chọn tiêu chuẩn và được đề cập trực tiếp trong tài liệu SFTP của chúng tôi như một client được hỗ trợ. Nó pure Python, xử lý SFTP gọn gàng và hoạt động tốt cho logic upload và download. Với các transfer rất lớn hoặc lặp lại thường xuyên, hãy gọi shell ra rsync qua SSH từ Python với subprocess — nó chỉ gửi các file đã thay đổi và resume các file bị ngắt, điều mà paramiko không làm được natively.

Q: Có public API để submit render job từ pipeline Python không? A: Chưa có. Một public REST API cho submission, status polling và output retrieval đang trong lộ trình phát triển, nhưng hiện tại không có public endpoint nào khả dụng. Các đường dẫn submission lập trình hiện tại là SuperRenders Client App và DCC submission plugin, tích hợp với môi trường scripting riêng của ứng dụng host như MAXScript hoặc Python bên trong DCC. Nếu pipeline của bạn bị tắc nghẽn cụ thể vì public submission API, hãy liên hệ support và chia sẻ use case — lộ trình được định hướng bởi yêu cầu pipeline thực tế.

Q: Làm thế nào để phát hiện render job đã hoàn thành khi không có status API? A: Poll thư mục output SFTP của job, /output/<job-id>/, và theo dõi số frame. Xử lý job như hoàn thành chỉ khi số lượng đạt đến tổng dự kiến và giữ ổn định qua các lần kiểm tra liên tiếp, để bạn không bắt đầu tải về khi frame vẫn đang được ghi. Đây là directory heuristic hơn là tín hiệu status chính thức, nhưng nó chỉ dựa vào các khả năng đang tồn tại hiện nay.

Q: Nên dùng SSH key hay password cho transfer tự động? A: Dùng SSH key. Hard-code password trong script là rủi ro bảo mật, và xác thực key chạy unattended mà không cần interactive prompt. Tạo ed25519 key, đăng ký phần public trong Settings → SFTP → SSH Keys, và bảo vệ private key bằng passphrase do SSH agent giữ. Vì xác thực hai yếu tố hiện chưa được hỗ trợ trên tài khoản, key cộng với passphrase của nó là biện pháp bảo mật thực tế mạnh nhất cho truy cập SFTP.

Q: Có thể upload archive .zip từ script không? A: Không — archive .zip không được hỗ trợ. Hãy repack thành .tar.gz (hoặc .tar / .7z), hoặc bỏ qua việc archive và để rsync transfer cây thư mục trực tiếp, thường là lựa chọn tốt hơn cho các dự án thay đổi giữa các lần upload. Giữ một lần upload đơn lẻ dưới khoảng 300 GB và dùng rsync --partial cho bất kỳ thứ gì lớn hơn để kết nối bị mất có thể resume thay vì restart.

Q: Có thể di chuyển dự án lớn bao nhiêu theo cách này? A: Transfer nhiều terabyte được hỗ trợ qua SFTP; giới hạn thực tế là băng thông upload của bạn, không phải giới hạn farm. Upload 1 TB ở 100 Mbps mất khoảng một ngày, vì vậy hãy lên kế hoạch theo link của bạn. Để đạt throughput tối đa trên kết nối fat hoặc long-haul, dùng lftp với parallel segment hoặc nhiều SFTP session đồng thời, vì một SFTP stream đơn bị giới hạn bởi overhead per-packet.

Q: Frame đã render của tôi có thể tải về trong bao lâu? A: Output được lưu giữ trong 45 ngày sau khi job hoàn thành, sau đó tự động xóa, và SFTP không kéo dài cửa sổ đó. Với pipeline unattended, hãy mirror output về archive cục bộ ngay khi nó xuất hiện — rsync pull hàng đêm của /output/<job-id>/ đảm bảo thời gian lưu giữ không bao giờ là lý do frame bị mất.

Q: Điều này khác gì so với hướng dẫn headless và unattended workflow của bạn? A: Hướng dẫn đó là bản đồ khái niệm — headless rendering có nghĩa là gì, cách chuẩn bị scene cho command-line rendering, và cách vòng lặp unattended phù hợp trên managed farm. Hướng dẫn này là người đồng hành ở mức code tập trung vào lớp transfer: paramiko và rsync thực tế mà bạn viết để đưa dự án lên và kéo frame xuống. Đọc hướng dẫn workflow để có cái nhìn tổng thể; dùng hướng dẫn này để triển khai.