Hướng dẫn sử dụng Blackblaze (B2)

wo24 · October 2, 2025, 1:00pm

Upload file lớn lên B2

File lớn hơn 5Gb sẽ bị hạn chế upload qua Browser GUI

Sử dụng `Backblaze` B2 CLI

1. Cài đặt

Bạn có 2 phương án chính: tải bản nhị phân sẵn hoặc cài qua Python.

Tải bản nhị phân (khuyến nghị nếu muốn đơn giản): truy cập trang cài đặt, tải bản Linux, rồi:

chmod +x b2-linux
sudo mv b2-linux /usr/local/bin/b2

Path `/usr/local/bin/b2` có thay đổi trên oem?

Không, đường dẫn /usr/local/bin/b2 gần như không thay đổi trên mọi bản Ubuntu, kể cả OEM.

Giải thích nhanh:

`/usr/local/bin` là chuẩn Linux Filesystem Hierarchy

Đây là thư mục chuẩn dùng để chứa các chương trình người dùng tự cài bằng tay (không phải từ package manager).
OEM (Dell, HP, Lenovo, System76…) không sửa đổi thư mục này.
Ubuntu bản tiêu chuẩn, bản OEM cài sẵn, bản LTS… đều giữ nguyên cấu trúc.

Khi nào có thể khác?

Chỉ khi:

Bạn cài vào một đường dẫn khác theo ý bạn (ví dụ: /opt/b2/b2).
Hoặc bạn cài trên distro không tuân chuẩn FHS (Alpine, NixOS…).

Nhưng Ubuntu OEM vẫn là Ubuntu, nên /usr/local/bin/b2 chắc chắn dùng được.

Kiểm tra nhanh

which b2

Hoặc:

ls -l /usr/local/bin/b2

Hoặc cài qua Python (chưa test)

Cài qua Python (nếu bạn dùng môi trường Python):

sudo apt update
sudo apt install python3-pip
pip3 install --upgrade b2

Install the Backblaze B2 Command-Line Tool

2. Cấp quyền và xác thực tài khoản

Sau khi cài xong, bạn cần xác thực với B2. Ví dụ:

b2 account authorize <keyID> <applicationKey>

Bạn cũng có thể sử dụng biến môi trường B2_KEY_ID và B2_APPLICATION_KEY để xác thực mà không lưu thông tin trên đĩa.

B2_APPLICATION_KEY (secret key) chỉ hiển thị đúng 1 lần khi tạo

Bạn không thể lấy lại (recover) Application Key cũ trên Backblaze B2 sau khi đã tạo xong.

Vì sao?

Application Key (secret key) chỉ hiển thị đúng 1 lần khi tạo
Sau đó hệ thống không lưu dạng plaintext → nên không thể xem lại
Đây là thiết kế bảo mật chuẩn (giống AWS, GitHub token, v.v.)

Bạn có thể làm gì thay thế?

1. Nếu còn đang đăng nhập (app / script vẫn chạy)

Key vẫn đang dùng được → chưa cần đổi ngay
Nhưng nên:
- Lưu lại key vào password manager (Bitwarden, KeePass, v.v.)
- Hoặc .env / secret manager

2. Nếu đã mất key → cách duy nhất

Tạo key mới

Trong B2:

Vào: App Keys
Create New Application Key
Gán lại quyền (bucket, read/write…)

3. Sau đó (quan trọng)

Update lại:
- rclone
- restic
- Docker container
- script backup

4. Nên xóa key cũ nếu không còn dùng

Tránh rò rỉ / bị abuse
Vì key cũ vẫn có quyền truy cập nếu chưa revoke

GitHub - Backblaze/B2_Command_Line_Tool: The command-line tool that gives easy access to all of the capabilities of B2 Cloud Storage · GitHub

Cấp quyền hạn chế cho `application keys`

Tham số <ApplicationKey> có bị khai thác khi tấn công local? Có encrypt chưa?

Ngắn gọn: Có — nếu máy bạn bị tấn công (local compromise), thì kẻ tấn công có thể đọc được key B2 được lưu bởi b2 authorize-account. Các key KHÔNG được mã hóa.

Mình giải thích kỹ hơn để bạn đánh giá mức độ rủi ro:

1. `b2 authorize-account` lưu gì, lưu ở đâu?

Khi bạn chạy:

b2 authorize-account <AccountID> <ApplicationKey>

CLI sẽ lưu access token + refresh data vào file config nằm tại:

~/.b2_account_info

Hoặc bản mới hơn dùng:

~/.cache/b2/account_info.json

File này không mã hóa, chỉ được bảo vệ bằng quyền Linux:

-rw-------  user  user   ...

2. Nếu máy bạn bị hack thì sao?

Nếu attacker có quyền đọc được file của user, thì:

Họ có thể lấy Application Key hoặc token.
Họ có thể dùng key đó để:
- Xem dữ liệu
- Xoá file
- Sync toàn bộ bucket
- Upload file độc hại
Các hành động đều được cấp quyền dựa vào scope của Application Key bạn tạo.

Không có mã hóa tích hợp trong B2 CLI, nên key được xem như plaintext.

3. Làm sao giảm rủi ro?

3.1 Dùng Application Key hạn chế quyền (khuyến nghị nhất)

Trong Backblaze B2 bạn có thể tạo key dạng:

Read-only
Chỉ cho phép 1 bucket
Giới hạn prefix path (VD: chỉ phép truy cập backup/server1/)

→ Khi key bị lộ, thiệt hại được giới hạn rất nhiều.

3.2 Tách user Linux

Tạo một user riêng chỉ dùng cho backup:

sudo adduser b2backup

Sau đó chạy CLI bằng user này → nếu user chính bị hack thì key không bị lộ.

3.3 Không lưu plaintext key

Bạn có thể chọn xác thực bằng biến môi trường, thay vì lưu file:

export B2_APPLICATION_KEY_ID=xxxx
export B2_APPLICATION_KEY=xxxx
b2 ...

→ Key biến mất khi restart shell.

Hoặc tạo script chạy dưới systemd và inject secret từ EnvironmentFile=.

3.4 Đặt phân quyền mạnh

chmod 600 ~/.b2_account_info

4. Kết luận

Tình huống	Key an toàn?	Giải thích
Máy không bị hack, user khác không có access	Có	Linux file permissions bảo vệ
Máy bị malware hoặc bị root/priv-esc	Không	File chứa key không mã hóa
Bạn dùng Application Key hạn chế scope	→ Giảm thiệt hại	Cách tốt nhất

Hạn chế ở quyền only-write là cách phòng thủ hiệu quả cho app-keys

Nếu app-keys lộ, kẻ xấu không thể read or list
Nghĩa là ngay cả over-write trùng tên cũng rất khó

Vào https://secure.backblaze.com/app_keys.htm
Add a New Application Key
Sử dụng quyền Write Only
Giới hạn Allow access to Bucket(s)
4.1. Uncheck Allow List All Bucket Names

Xóa cấp quyền và xác thực tài sản

b2 account clear

Xóa toàn bộ thông tin đăng nhập (access token, refresh token, Application Key) khỏi máy.
Hợp với tất cả các phiên bản CLI (v3+), bao gồm cả những bản dùng cache theo XDG.
Không cần phải tìm file config hoặc dùng rm thủ công.
CLI sẽ coi như chưa từng authorize.

Sau đó, thử lại:

b2 ls

→ Sẽ báo lỗi ERROR: account not authorized → xác nhận account đã được xóa.

3. Sử dụng các lệnh cơ bản

b2 -h hoặc b2 <command> -h để xem hướng dẫn chi tiết

b2 ls

Liệt kê bucket (không thể ls dưới quyền write-only):
Nhưng vẫn check được có tồn tại app-keys chưa

b2 ls

(phiên bản cũ là b2 list-buckets)

List chỉ trong `một bucket cụ thể`

Cú pháp chuẩn:

1. Liệt kê trong một bucket

b2 ls <bucketName>

Ví dụ:

b2 ls my-backup-bucket

2. Liệt kê trong một path (prefix) trong bucket

Nếu bạn chỉ muốn xem các file bên trong một folder:

b2 ls <bucketName> <folder/path>

Ví dụ:

b2 ls my-backup-bucket server1/logs/

Hoặc xem sâu toàn bộ tree:

b2 ls --recursive my-backup-bucket server1/

3. Các tuỳ chọn hữu ích

Tuỳ chọn	Ý nghĩa
`--long`	Hiện dung lượng + SHA1
`--versions`	Hiện tất cả version file
`--recursive`	Liệt kê toàn bộ subfolder
`--json`	Xuất JSON (dùng cho automation)

Ví dụ đầy đủ:

b2 ls --long --recursive my-backup-bucket photos/2024/

b2 file upload

Nên dùng với quyền write-only, upload từng file

b2 file upload [bucketName] \
    [localFilePath] \
    [b2FileName] \
    --threads 8 \
    --min-part-size 1073741824

[bucketName]
Tên bucket, ví dụ bucket-backup
[localFilePath]
Đường dẫn local-file, ví dụ file-name (current folder), hoặc /path/to/file-name
[b2FileName]
Tên file (hoặc kèm đường dẫn) trên b2-bucket
Ví dụ file-name (giữ nguyên hoặc đổi tên file)
Hoặc folder/file-name (cho b2://<bucket>/folder/file-name)
--threads
Multi-thread upload giúp CLI retry từng part nếu fail, giảm rủi ro timeout do request dài
--min-part-size
Chia file >300GB thành chunks 1GB → giảm khả năng timeout.
1 GB = 1073741824 bytes
100 Mb = 104857600 bytes

[!info] Nếu big-file upload bị 408 error
Có thể check upload-file failed (phải đủ permission):
b2 file large unfinished list b2://yourBucket
Cancel bằng lệnh sau:
b2 file large unfinished cancel b2id://yourFileId

Bổ sung tham số `--no-progress` (testing: big-upload -> tránh lỗi 408)

`--no-progress` là gì?

Mặc định, b2 file upload hiển thị một thanh tiến trình (progress bar) trong terminal:

25%|▎| 84.9G/335G [2:00:58<5:55:43, ...

Để hiển thị thanh này, CLI phải:

liên tục cập nhật output
lock STDOUT nhiều lần/giây
tính toán tốc độ dựa trên nhiều biến
flush buffer để hiện thị realtime

Khi upload file lớn (>50–100GB) trên mạng không ổn định, progress bar có thể gây chậm, thậm chí gây timeout 408 do event-loop bị chiếm tài nguyên I/O.

`--no-progress` giúp gì?

Khi bạn thêm:

--no-progress

CLI sẽ:

Tắt hoàn toàn progress bar

Không còn update “% upload”, không in liên tục ra terminal.

Giảm I/O lên terminal

Điều này làm CLI nhẹ hơn → ổn định hơn trong upload dài.

Giảm nguy cơ “408 request_timeout”

Vì các thread upload không còn bị block bởi UI updating.

Upload nhanh hơn trong nhiều trường hợp

Nhất là khi dùng nhiều --threads.

Kết hợp tốt với `--threads` và multipart

Không bị rối UI khi 4–8 threads chạy song song.
Hạn chế xung đột output.

Khi nên dùng `--no-progress`

Tình huống	Có nên dùng?
Upload file nhỏ (<2GB)	Không cần
Upload file lớn (>20GB)	Nên dùng
Upload file cực lớn (100–500GB)	Bắt buộc
Dùng nhiều threads (4–16)	Giảm rối output
Upload qua SSH, VPN, tmux, screen	Giảm lỗi I/O
Máy server, ít GPU/IO	Giúp ổn định

Ví dụ upload tối ưu (ổn định nhất)

b2 file upload \
  --threads 4 \
  --min-part-size 1073741824 \
  --no-progress \
  backups ./folder/data-img.tar.gpg

Đây là cấu hình ổn định hơn cho file 335GB upload.

Tóm tắt nhanh

Tính năng	Mặc định	Khi bật `--no-progress`
Hiển thị progress bar	Có	Không
Tải CPU	Trung bình	Thấp hơn
Tải I/O terminal	Cao	Gần bằng 0
Nguy cơ 408 timeout	Cao khi file lớn	Thấp
Ổn định khi upload nhiều thread	Trung bình	Rất ổn

b2 file download

Để download file từ B2 bằng CLI của Backblaze, bạn dùng lệnh:

b2 file download <B2_URI> <localFileName>

<B2_URI>: có dạng b2://folder/file-name

Ví dụ cụ thể `b2 file download`

b2 file download my-bucket backup/db.sql ./db.sql

Nghĩa là:

my-bucket = tên bucket
backup/db.sql = đường dẫn file trên B2
./db.sql = file lưu về máy local

b2 sync

Dùng tốt trong trường hợp thay b2 file download và b2 file upload đồng bộ cùng lúc nhiều file trong một folder (b2 file chỉ có thể dùng cho từng file riêng lẻ).

Download toàn bộ file trong folder

Giữ nguyên cấu trúc thư mục

Có thể resume nếu bị gián đoạn

Chỉ download file thay đổi (incremental)

Quyền `write-only` không thể `sync`

Quyền write-only trên Backblaze B2 cho phép upload file vào bucket.
Nó không cho phép đọc hoặc liệt kê file trong bucket.

Khi dùng `b2 sync` với `write-only` key

b2 sync /local/path b2://my-bucket/path sẽ thất bại nếu CLI cần so sánh file cũ trên bucket để quyết định file nào cần upload, skip, overwrite.
Lý do: b2 sync thường thực hiện:
1. Liệt kê file trong bucket (listFiles)
2. So sánh với file local
3. Upload file mới / overwrite nếu cần

→ Nếu key không có quyền đọc/list, bước 1 sẽ fail → unauthorized.

Đồng bộ thư mục lên hoặc từ B2:

b2 sync -v </local/path> <b2://my-bucket/path>

hoặc ngược lại từ B2 về máy:

b2 sync -v <b2://my-bucket/path> </local/path>

Bạn có thể thêm các tuỳ chọn như --delete, --threads N, --exclude-regex, …

`--threads` trong `b2 sync` thực sự làm gì?

Theo docs của Backblaze:

Cú pháp có:

b2 sync [--threads N] ...

Ý nghĩa:

File uploads are done in parallel in multiple threads

Default:
10 threads
Có thể chỉnh từ 1 → ~99

Vậy `--threads` trong `b2 sync` thực sự làm gì?

Điều khiển số file xử lý song song
Áp dụng cho:
- upload
- download
- bucket → bucket

Ví dụ:

b2 sync --threads 25 b2://my-bucket ./local

→ tải nhiều file cùng lúc → tăng throughput

Nhưng có một điểm rất quan trọng (hay bị hiểu nhầm)

`--threads` KHÔNG giống:

b2 file download --threads N --min-part-size …

Khác biệt:

Tính năng	`b2 sync --threads`	`b2 file download`
Parallel	nhiều file cùng lúc	chia nhỏ 1 file
Multi-part 1 file
`--min-part-size`
Tối ưu file lớn	hạn chế	tốt

Nghĩa là:

sync → parallel theo file
file download → parallel trong 1 file

`b2 sync` hiển thị `progress status` không tốt

Rất “cùi” so với b2 file download hay b2 file upload

So sánh trực tiếp

`b2 file download`

Có progress bar rõ ràng
Hiển thị:
- % hoàn thành
- tốc độ
- dung lượng đã tải
Trải nghiệm giống tool hiện đại

`b2 sync`

Mặc định chỉ log kiểu:

upload file1.txt
download file2.zip

Không có:

progress bar
% hoàn thành
tốc độ realtime
tổng tiến trình

Có cách “cải thiện” không?

Dùng `--verbose`

b2 sync --verbose b2://bucket/folder ./local

Sẽ thấy thêm:

file nào đang xử lý
chi tiết hơn chút

Nhưng:
→ vẫn không có progress đúng nghĩa

How to Use the B2 Sync Command with the Backblaze B2 Command-Line Tool

Các vấn đề về file-upload trên B2

B2 sẽ cho bạn upload 10 Gb ban đầu miễn phí

Trên `backblaze` (B2), khi upload trùng tên file thì sao?

Trên Backblaze B2 (dịch vụ lưu trữ object storage của Backblaze), việc upload trùng tên file sẽ phụ thuộc vào bucket của bạn được cấu hình ở chế độ nào:

Nếu bucket ở chế độ mặc định (“Keep all versions”)

Khi bạn upload một file trùng tên (cùng đường dẫn “file name” trong bucket), Backblaze không ghi đè.
Nó sẽ giữ lại phiên bản cũ và tạo thêm một phiên bản mới.
Bạn có thể truy vấn API hoặc bật “Show Hidden Files” để thấy các version trước.
Mỗi lần upload sẽ tạo ra một file version riêng biệt (có fileId khác nhau).

Nếu bucket bật chế độ “Keep only the last version”

Lúc này Backblaze sẽ tự động xóa phiên bản cũ (đặt trạng thái “hidden”) và chỉ giữ lại bản mới nhất.
Nghĩa là hành vi gần giống “overwrite”, nhưng thực tế vẫn có một bản “hidden file” nếu bạn query API (trừ khi bạn cấu hình auto-delete hoàn toàn sau X ngày).

Tóm gọn:

Backblaze không ghi đè trực tiếp như ổ cứng.
Nó dùng versioning để quản lý file trùng tên.
Bạn có thể chọn giữ nhiều version, hoặc chỉ giữ phiên bản cuối cùng.

Vậy nó có tốn dung lượng storage ko?

Trên Backblaze B2, khi bạn upload file trùng tên trong bucket có chế độ “Keep only the last version”, thì:

Phiên bản cũ sẽ được đánh dấu là “hidden”.
Dung lượng lưu trữ vẫn tính cho file hidden đó, bởi vì nó thực sự còn tồn tại trên hệ thống.
Chỉ khi bạn thiết lập Lifecycle Rules để xóa file hidden sau X ngày (hoặc ngay lập tức) thì dung lượng mới được giải phóng.

Ví dụ:

Bạn có file video.mp4 1GB.
Upload lại video.mp4 (mới) cũng 1GB.
Nếu bucket để Keep only last version nhưng không có rule xóa:
→ Storage = 2GB (1GB file mới + 1GB file cũ bị ẩn).
Nếu bạn đặt Lifecycle Rule “Delete hidden files immediately”:
→ Storage chỉ còn 1GB (file mới).

Nói cách khác: File hidden vẫn bị tính vào dung lượng, cho tới khi bạn có rule dọn dẹp.

Snapshot trên B2 dùng để làm gì?

Trong hệ sinh thái Backblaze B2, khái niệm Snapshot thường khiến nhiều người nhầm với “file version” hay “hidden file”, nhưng thực ra nó khác hẳn:

Snapshot trong `Backblaze B2` là gì?

Snapshot = một gói (bundle) dữ liệu được Backblaze đóng gói từ bucket hoặc từ một nhóm file/folder.
Bạn có thể tạo snapshot từ Web UI hoặc API.
Nó được xuất ra thành file nén (zip hoặc tương tự) rồi lưu vào chính B2 hoặc tải về máy.

Mục đích sử dụng Snapshot

Backup cứng (point-in-time copy)

Bạn có thể chụp nhanh toàn bộ bucket hoặc một thư mục tại thời điểm hiện tại.
Hữu ích khi muốn lưu “ảnh chụp” dữ liệu trước khi thay đổi lớn.

Tải xuống dễ dàng

Thay vì phải tải từng file qua API hoặc CLI, snapshot cho phép bạn tạo một file bundle duy nhất để tải.
Ví dụ: bạn có bucket chứa 10.000 file, bạn tạo snapshot → sẽ được 1 file snapshot.zip để download về.

Chia sẻ dữ liệu

Snapshot có thể được giữ như một bản đóng gói cố định để chia sẻ, thay vì mở bucket public.

Đảm bảo khôi phục

Nếu bạn chạy lifecycle rules (xóa version cũ, xóa file hidden) mà muốn lưu lại bản đầy đủ ở thời điểm nào đó, snapshot giúp bạn giữ nguyên bộ dữ liệu.

So sánh nhanh với “versioning/hidden file”

Versioning: tự động lưu nhiều phiên bản khi bạn upload trùng tên.
Snapshot: do bạn chủ động tạo, giống như backup “point-in-time”, gói dữ liệu thành 1 file snapshot.

Nói nôm na:

Versioning/hidden file = lịch sử file riêng lẻ.
Snapshot = chụp nguyên trạng bucket/folder để backup hoặc tải nhanh.

Replication có cần tạo để files an toàn?

Backblaze B2 Cloud Replication automatically copies data from one bucket to another for redundancy, compliance, and fast local access

→ Việc này đồng nghĩa là không tạo Replication thì không đảm bảo file đã lưu an toàn?

Không hẳn , nên hãy yên tâm.

1. An toàn dữ liệu mặc định (không cần replication)

Backblaze B2 đã mặc định lưu dữ liệu an toàn trong cùng một data center theo mô hình erasure coding và nhiều bản sao nội bộ.
Nghĩa là nếu một ổ cứng, hoặc thậm chí một server trong trung tâm dữ liệu bị hỏng → file của bạn vẫn an toàn vì Backblaze đã tự động phân tán block dữ liệu trong cùng một vùng.
Điều này đảm bảo durability rất cao (99.999999999% ~ “11 số 9”), tương đương Amazon S3.

Nói cách khác: chỉ upload vào 1 bucket thôi cũng đã an toàn ở mức storage enterprise rồi.

2. Vậy Replication dùng để làm gì?

Replication của Backblaze B2 không phải là để tránh mất dữ liệu do hỏng ổ cứng (cái đó đã được đảm bảo).

Mà nó để giải quyết 3 nhu cầu:

Đa vùng địa lý (geo-redundancy)

Nếu bạn muốn dữ liệu có bản sao ở nhiều data center khác nhau (ví dụ một ở Mỹ, một ở Châu Âu) → phòng rủi ro thiên tai hoặc sự cố toàn vùng.

Tuân thủ (compliance)

Một số quy định (HIPAA, GDPR, …) yêu cầu dữ liệu phải có bản sao ở khu vực nhất định hoặc nhiều nơi.

Hiệu năng truy cập địa phương

Nếu người dùng ở Châu Á tải file, bạn có thể tạo replication ở data center gần đó → truy cập nhanh hơn, ít độ trễ hơn.

Kết luận

Không bật replication → dữ liệu vẫn rất an toàn, vì Backblaze đã có cơ chế bảo vệ nội bộ.
Bật replication → chỉ cần khi bạn có nhu cầu đa vùng, tuân thủ pháp lý, hoặc tối ưu tốc độ.

Hướng dẫn sử dụng Blackblaze (B2)

Upload file lớn lên B2

Sử dụng Backblaze B2 CLI

1. Cài đặt

/usr/local/bin là chuẩn Linux Filesystem Hierarchy

Khi nào có thể khác?

Kiểm tra nhanh

2. Cấp quyền và xác thực tài khoản

Vì sao?

Bạn có thể làm gì thay thế?

1. Nếu còn đang đăng nhập (app / script vẫn chạy)

2. Nếu đã mất key → cách duy nhất

3. Sau đó (quan trọng)

4. Nên xóa key cũ nếu không còn dùng

Cấp quyền hạn chế cho application keys

1. b2 authorize-account lưu gì, lưu ở đâu?

2. Nếu máy bạn bị hack thì sao?

3. Làm sao giảm rủi ro?

3.1 Dùng Application Key hạn chế quyền (khuyến nghị nhất)

3.2 Tách user Linux

3.3 Không lưu plaintext key

3.4 Đặt phân quyền mạnh

4. Kết luận

Xóa cấp quyền và xác thực tài sản

3. Sử dụng các lệnh cơ bản

b2 ls

1. Liệt kê trong một bucket

2. Liệt kê trong một path (prefix) trong bucket

3. Các tuỳ chọn hữu ích

b2 file upload

--no-progress là gì?

--no-progress giúp gì?

Tắt hoàn toàn progress bar

Giảm I/O lên terminal

Giảm nguy cơ “408 request_timeout”

Upload nhanh hơn trong nhiều trường hợp

Kết hợp tốt với --threads và multipart

Khi nên dùng --no-progress

Ví dụ upload tối ưu (ổn định nhất)

Tóm tắt nhanh

b2 file download

b2 sync

Khi dùng b2 sync với write-only key

Vậy --threads trong b2 sync thực sự làm gì?

Nhưng có một điểm rất quan trọng (hay bị hiểu nhầm)

--threads KHÔNG giống:

Khác biệt:

So sánh trực tiếp

b2 file download

b2 sync

Có cách “cải thiện” không?

Dùng --verbose

Các vấn đề về file-upload trên B2

Trên backblaze (B2), khi upload trùng tên file thì sao?

Vậy nó có tốn dung lượng storage ko?

Snapshot trên B2 dùng để làm gì?

Snapshot trong Backblaze B2 là gì?

Mục đích sử dụng Snapshot

So sánh nhanh với “versioning/hidden file”

Replication có cần tạo để files an toàn?

1. An toàn dữ liệu mặc định (không cần replication)

2. Vậy Replication dùng để làm gì?

Kết luận

Sử dụng `Backblaze` B2 CLI

`/usr/local/bin` là chuẩn Linux Filesystem Hierarchy

Cấp quyền hạn chế cho `application keys`

1. `b2 authorize-account` lưu gì, lưu ở đâu?

`--no-progress` là gì?

`--no-progress` giúp gì?

Kết hợp tốt với `--threads` và multipart

Khi nên dùng `--no-progress`

Khi dùng `b2 sync` với `write-only` key

Vậy `--threads` trong `b2 sync` thực sự làm gì?

`--threads` KHÔNG giống:

`b2 file download`

`b2 sync`

Dùng `--verbose`

Trên `backblaze` (B2), khi upload trùng tên file thì sao?

Snapshot trong `Backblaze B2` là gì?