Nhưng thật ra tôi dùng scp ngày càng ít hơn. Không phải vì nó tệ, mà vì rsync làm được tất cả những gì scp làm, cộng thêm một đống thứ mà scp không bao giờ làm được.

Hai cái hay nhất: chỉ transfer phần thay đổi và resume được khi đứt kết nối. Với file lớn hoặc deploy thường xuyên, hai điểm này thôi là đủ để chuyển sang rsync rồi.

Cú pháp cơ bản

rsync [options] source destination

Nhìn quen không? Đúng rồi - giống hệt scp. Nếu bạn đã dùng scp thành thạo thì học rsync chỉ mất thêm 10 phút.

Trailing slash - thứ gây confuse nhiều nhất

Đây là điểm khác biệt lớn nhất so với scp, và cũng là thứ tôi thấy mọi người hay bị nhầm nhất.

# Có slash - copy NỘI DUNG bên trong folder
rsync -av ./dist/ user@server:/var/www/
# Kết quả: /var/www/index.html, /var/www/app.js ...

# Không có slash — copy CẢ folder (kèm tên)
rsync -av ./dist user@server:/var/www/
# Kết quả: /var/www/dist/index.html, /var/www/dist/app.js ...

Quy tắc đơn giản để nhớ: dấu slash = mở folder ra, lấy nội dung bên trong.

Khi deploy web app, hầu hết trường hợp bạn muốn có slash - copy nội dung dist/ thẳng vào /var/www/, không phải tạo thêm folder dist lồng bên trong.

Combo mặc định nên dùng

rsync -avzP

Bốn flag này tôi gần như luôn dùng cùng nhau:

• -a - Archive mode, gộp -rlptgoD: recursive + giữ nguyên permission, timestamps, symlinks...

• -v - Verbose, thấy file nào đang được transfer

• -z - Compress, giảm data transfer - hữu ích với file text, code

• -P - Hiện progress bar + resume được khi đứt giữa chừng

Các options hay dùng

• -n hoặc --dry-run - Giả lập, không thực sự copy. Luôn chạy cái này trước khi thực thi lần đầu

• --delete - Xóa file ở đích nếu ở nguồn đã xóa. Dùng khi muốn sync thực sự

• --exclude - Bỏ qua file/folder chỉ định

• --include - Include lại sau khi exclude

• -e - Chỉ định SSH command (key, port)

• --checksum - So sánh bằng checksum thay vì size + timestamp

• --bwlimit=1000 - Giới hạn bandwidth (KB/s)

• --backup - Backup file trước khi override

Upload - Local to Remote

# Upload folder build lên server
rsync -avzP ./dist/ ubuntu@server:/var/www/html/

# Với SSH key
rsync -avzP -e "ssh -i ~/.ssh/key.pem" ./dist/ ubuntu@server:/var/www/html/

# Với SSH config alias — tiện nhất
rsync -avzP ./dist/ myserver:/var/www/html/

# Dry run trước để kiểm tra
rsync -avzP --dry-run ./dist/ myserver:/var/www/html/

Download - Remote to Local

# Download folder từ server về
rsync -avzP user@server:/var/www/html/ ./local-backup/

# Backup database dump
rsync -avzP user@db-server:/tmp/dumps/ ~/backups/db/

# Download log files
rsync -avzP user@server:/var/log/nginx/ ./logs/

--delete - Sync thực sự

Mặc định rsync chỉ thêm và cập nhật, không xóa. Muốn đích giống hệt nguồn:

rsync -avzP --delete ./dist/ user@server:/var/www/html/

⚠️ Cẩn thận với --delete - file ở server mà không có ở local sẽ bị xóa vĩnh viễn. Luôn --dry-run trước khi dùng lần đầu.

# Kiểm tra trước
rsync -avzP --delete --dry-run ./dist/ user@server:/var/www/html/

# Thấy ổn rồi mới chạy thật
rsync -avzP --delete ./dist/ user@server:/var/www/html/

--exclude - Bỏ qua file không cần thiết

# Exclude 1 folder
rsync -avzP --exclude 'node_modules' ./ user@server:/app/

# Exclude nhiều thứ
rsync -avzP \
  --exclude 'node_modules' \
  --exclude '.git' \
  --exclude '.env' \
  --exclude '*.log' \
  --exclude 'dist' \
  ./ user@server:/app/

# Dùng file exclude — giống .gitignore
rsync -avzP --exclude-from='.rsyncignore' ./ user@server:/app/

File .rsyncignore:

node_modules/
.git/
.env
*.log
dist/
__pycache__/
*.pyc

Usecase thực tế

Deploy web app

npm run build

rsync -avzP --delete \
  --exclude '.env' \
  ./dist/ ubuntu@myserver:/var/www/myapp/

Backup định kỳ với timestamp

# Backup thủ công
rsync -avzP user@server:/var/data/ ~/backups/$(date +%Y-%m-%d)/

# Kết hợp cron — backup mỗi ngày lúc 2am
# crontab -e
0 2 * * * rsync -avzP user@server:/var/data/ ~/backups/$(date +\%Y-\%m-\%d)/

Backup với --backup - giữ lại file cũ trước khi overwrite

rsync -avzP --backup --backup-dir=/backup/$(date +%Y%m%d) \
  user@server:/important/ ./local/

Sync qua port SSH khác

rsync -avzP -e "ssh -p 2222 -i ~/.ssh/key.pem" \
  ./dist/ user@server:/var/www/

Resume file lớn bị đứt giữa chừng

-P đã bao gồm --partial nên chỉ cần chạy lại đúng lệnh cũ - rsync tự tiếp tục từ chỗ dừng.

rsync -avzP largefile.iso user@server:/tmp/
# Bị đứt → chạy lại y chang, nó tiếp tục từ chỗ dừng

Một lỗi nhỏ trong bản gốc

Trong bảng options ban đầu có ghi --postgres - đây là typo, không có flag nào tên vậy. -P thực ra là viết tắt của --progress --partial. Tôi đã sửa lại trong bài này rồi.

Vậy là xong phần core của rsync. Từ giờ mỗi khi deploy hay backup, thay scp bằng rsync -avzP là an toàn hơn nhiều rồi.

Bài tiếp theo tôi sẽ viết về step-ca - tự dựng private Certificate Authority cho internal services. Nếu bạn đang chạy homelab hoặc internal tooling, bài đó sẽ hữu ích.

Bài này không phải man page. Tôi sẽ chỉ ghi lại những thứ tôi thực sự dùng trong công việc hàng ngày.

SCP là gì?

scp (Secure Copy Protocol) là công cụ copy file chạy trên nền SSH. Nghĩa là mọi thứ bạn transfer đều được mã hóa, và bạn dùng lại đúng SSH key/config mà bạn đã có - không cần setup thêm gì.

Cú pháp cơ bản

scp [options] source destination

Trong đó source hoặc destination có thể là local hoặc user@host:path. Chỉ cần nhớ quy tắc này là dùng được 90% các trường hợp.

Upload - Local to Remote

# Copy 1 file
scp file.txt user@192.168.1.10:/home/user/

# Copy vào thư mục cụ thể với tên mới
scp file.txt user@192.168.1.10:/home/user/newname.txt

# Copy cả folder (recursive)
scp -r ./myproject user@192.168.1.10:/home/user/

# Dùng SSH key thay vì password
scp -i ~/.ssh/my_key.pem file.txt ubuntu@13.214.x.x:/home/ubuntu/

Lưu ý nhỏ: Nếu bạn đã config ~/.ssh/config với alias cho server thì dùng luôn alias đó được, không cần gõ IP dài. Ví dụ: scp file.txt myserver:/home/ubuntu/

Download - Remote to Local

# Download 1 file về thư mục hiện tại
scp user@192.168.1.10:/home/user/file.txt .

# Download về path cụ thể
scp user@192.168.1.10:/home/user/file.txt ~/Downloads/file.txt

# Download cả folder
scp -r user@192.168.1.10:/home/user/myproject ./local-copy

Cái hay ở đây là chỉ cần đổi vị trí source và destination so với lúc upload. Không có lệnh riêng cho “download” - logic hoàn toàn đối xứng.

Remote to Remote

# Copy thẳng từ server A sang server B (không qua local)
scp user1@server1:/path/file.txt user2@server2:/path/

Cái này ít người biết. Thay vì download về local rồi upload lên, bạn có thể copy thẳng giữa 2 server. Hữu ích khi file lớn và băng thông local bị hạn chế.

Cảnh báo: Tính năng này hoạt động bằng cách máy local mở 2 kết nối SSH song song. Một số cấu hình server strict có thể block hoặc không hoạt động như kỳ vọng. Nếu gặp vấn đề, dùng rsync hoặc SSH vào server A rồi scp từ đó sẽ chắc chắn hơn.

Các options hay dùng

• -i key.pem - Chỉ định SSH private key

• -P 2222 - SSH port khác (chú ý -P viết hoa, khác với ssh -p thường)

• -r - Recursive, copy cả folder

• -p - Giữ nguyên permission và timestamps

• -C - Compress data khi transfer, hữu ích với file text lớn

• -v - Verbose, bật khi debug lỗi kết nối

• -q - Quiet, tắt progress bar, dùng trong script

• -l 1000 - Giới hạn bandwidth (Kbit/s), dùng khi không muốn chiếm hết đường truyền

Khi nào thì dùng rsync thay vì scp?

scp tốt cho việc copy đơn giản. Nhưng nếu bạn đang:

• Sync folder lớn và muốn chỉ transfer phần thay đổi (không copy lại toàn bộ)

• Cần resume khi kết nối bị đứt giữa chừng

• Deploy code thường xuyên lên server

...thì rsync sẽ phù hợp hơn. Tôi sẽ viết về rsync trong bài sau.

Một vài lỗi thường gặp

“Permission denied” - Thường do SSH key sai hoặc user không có quyền ghi vào thư mục đích. Kiểm tra lại -i key và quyền của folder destination.

“No such file or directory” - Path trên remote cần tồn tại trước. scp không tự tạo folder như rsync —-mkpath. SSH vào server tạo folder trước rồi mới copy.

Port không phải 22 - Nhớ dùng -P viết hoa (khác với ssh -p thường). Đây là cái tôi vẫn hay gõ sai.

Bài tiếp theo tôi sẽ viết về rsync - mạnh hơn scp trong hầu hết use case thực tế, và một số pattern tôi hay dùng khi deploy. Nếu có câu hỏi gì về bài này, comment bên dưới nhé.

Về mặc lý thuyết, IoC là một nguyên lý thiết kế mà trong đó luồng điều khiển (flow of control) của một chương trình bị đảo ngược so với lập trình cấu trúc truyền thống.

• Trong lập trình truyền thống: Mã nguồn của nhà phát triển (high-level code) trực tiếp gọi các thư viện hoặc các hàm để thực thị logic. Nhà phát triển nắm quyền kiểm soát toàn bộ vòng đời của thực thể.

• Trong IoC: Một framework hoặc một thành phần hạ tầng đóng vai trò là chuơng trình chính. Nó sẽ triệu hồi (call back) mã nguồn của nhà phát triển tại các thời điểm mở rộng (extension points) đã định nghĩa trước.

Định nghĩa hàn lâm: IoC là sự dịch chuyển trách nhiệm quản lý luồng thực thi và vòng đời đối tượng từ mã nguồn ứng dụng sang một container hoặc framework.

2. Dependency Injection (DI) - Hiện thực hoá sự lỏng lẻo (Loose Coupling)

DI được coi là một mẫu hình đặc biệt của IoC, tập trung vào việc quản lý các mối quan hệ (dependencies) giữa các thành phần.

Theo quan điểm hệ thống, một đối tượng không nên có tri thức về cách cấu hình hoặc khởi tạo sự phụ thuộc của nó. Thay vào đó, trách nhiệm này được tách rời (decoupled) và chuyển giao cho một thực thể bên ngoài (injector).

Có 3 thành phần trong mô hình DI:

1. Client: Đối tượng cần sử dụng dịch vụ

2. Service (Dependency): Đối tượng cung cấp dịch vụ

3. Injector: Thành phần thực hiện việc cài đặt (inject) Service vào Client

3. Mối quan hệ với Nguyên lý Nghịch đảo Phụ thuộc (Dependency Inversion Principle - DIP)

Để hiểu sâu về IoC/DI ở mức hàn lâm, ta phải nhắc đến DIP (D trong nguyên lý SOLID). DIP đưa ra hai quy tắc cốt lõi:

1. Các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hau đề phải phụ thuộc và sự trừu tượng (Abstractions)

2. Sự trừu tượng không nên phụ thuộc vào chi tiết. Chi tiết phải phụ thuộc và sự trừu tượng

Lập luận: DI chính là kỹ thuật để thực hiện DIP. Bằng cách “tiêm“ một interface vào constructor, ta đảm bảo module cấp cao chỉ giao tiếp với sự trừu tượng, từ đó triệt tiêu sự phụ thuộc và cài đặt cụ thể (Concrete Implementation).

HighLevelModule → Interface ← LowLevelModule

4. Tổng kết

• IoC là một Meta-pattern (mẫu hình cao cấp) định nghĩa lại quyền hạn của các thành phần trong hệ thống.

• DI là một design pattern cụ thể hoá việc chuyển giao trách nhiệm khởi tạo đối tượng

• IoC Container là một Management Layer (lớp quản lý) chịu trách nhiệm thực thi các quy tắc về phạm vi (Scope - Singleton, Transient, Scoped) và vòng đời (Lifecycle) của các thành phần trong hệ thống.

5. Minh hoạ

interface MessageService {
    send(message: string): string;
}

class SmsService implements MessageService {
    send(message: string) {
        return 'Sms Sent:' + message;
    }
}

class EmailService implements MessageService {
    send(message: string) {
        return 'Email Sent: ' + message;
    }
}

class NotificationService {
    private messageService: MessageService;

    constructor(messageService: MessageService) {
        this.messageService = messageService;
    }

    sendAuth(message: string) {
        console.log('Sending...');
        const result = this.messageService.send(message);
        console.log(result);
    }
}

const emailService = new EmailService();
const authService = new NotificationService(emailService);
authService.sendAuth('Hello, you got fired');

Nhìn vào đoạn code mẫu này, chúng ta sẽ thấy nó có giá trị khi chúng ta cần bổ sung hoặc thay đổi những hình thức gửi thông báo. Ví dụ chúng ta cần thêm hình thức gửi qua Telegram, chỉ cần thêm class TelegramService, sau đó sử dụng một cách điệu nghệ phương thức mới mà không cần phải sửa bất kỳ dòng code nào của NotificationService :)