Thực nghiệm cấu hình Bareos: Job, FileSet, Schedule, Pool nối với nhau thế nào

Cài xong Bareos, mở thư mục cấu hình ra sẽ thấy hàng chục file nhỏ nằm rải trong nhiều thư mục con. Chúng không độc lập với nhau: một job backup chỉ chạy được khi năm, sáu resource khác nhau trỏ đúng vào nhau. Hiểu được sợi dây nối các resource đó thì đọc cấu hình Bareos không còn đáng sợ.

Bài trước đã dựng xong Director, Storage Daemon, catalog PostgreSQL và WebUI. Hệ thống chạy được nhưng chưa backup gì cả. Bài này trả lời câu hỏi tiếp theo: cấu hình Bareos được tổ chức ra sao, các resource Job, FileSet, Schedule, Pool nối với nhau thế nào, và viết một bộ file hoàn chỉnh để backup máy chủ web01.

Cấu hình nằm ở đâu

Các bản Bareos gần đây dùng cách tổ chức “mỗi resource một file”. Mỗi daemon có một thư mục riêng dưới /etc/bareos/, và bên trong là các thư mục con theo loại resource:

/etc/bareos/
├── bareos-dir.d/        # cấu hình Director
│   ├── catalog/
│   ├── client/
│   ├── console/
│   ├── director/
│   ├── fileset/
│   ├── job/
│   ├── jobdefs/
│   ├── messages/
│   ├── pool/
│   ├── profile/
│   ├── schedule/
│   └── storage/
├── bareos-sd.d/         # cấu hình Storage Daemon
└── bareos-fd.d/         # cấu hình File Daemon (trên từng máy chủ nguồn)

Director đọc mọi file *.conf trong các thư mục này khi khởi động hoặc khi nhận lệnh reload. Tên file chỉ để người đọc dễ tìm. Thứ Director dùng để nối các resource với nhau là dòng Name = "..." bên trong file. Quy ước thường gặp là đặt tên file trùng với tên resource, ví dụ job/backup-web01.conf chứa Name = "backup-web01".

Cách chia nhỏ này có lợi rõ khi hệ thống lớn dần. Thêm một máy chủ là thêm vài file, xoá một máy chủ là xoá vài file, không phải sửa một file khổng lồ dùng chung. Nó cũng mở đường cho việc sinh cấu hình bằng công cụ, chủ đề của bài 11.

Sáu resource và cách chúng trỏ vào nhau

Trung tâm của mọi thứ là resource Job. Bản thân Job gần như không chứa thông tin gì. Nó chỉ trả lời câu hỏi “ai, cái gì, khi nào, ghi vào đâu” bằng cách trỏ tới các resource khác:

JobDefs là khuôn mẫu. Một Job khai JobDefs = "..." sẽ thừa hưởng mọi thiết lập trong khuôn đó. Giá trị nào Job tự khai lại thì giá trị của Job thắng. Nhờ vậy, năm mươi máy chủ web có thể dùng chung một JobDefs, mỗi Job chỉ còn ba bốn dòng riêng.

Một điểm hay bị bỏ qua: Pool quyết định retention, không phải Job. Muốn một nhóm máy chủ giữ bản backup lâu hơn, bạn đổi Pool mà nhóm đó ghi vào, chứ không sửa từng Job. Bài 5 sẽ đi sâu vào chuyện này.

Làm thật: bộ file backup máy chủ web01

Giả sử web01 (địa chỉ 192.0.2.21) chạy một website PHP. Cần lấy mã nguồn trong /var/www và cấu hình trong /etc, bỏ qua thư mục cache. Trên máy chủ backup, ta tạo năm file.

Client: máy chủ nguồn

# /etc/bareos/bareos-dir.d/client/web01-fd.conf
Client {
  Name = "web01-fd"
  Address = "192.0.2.21"
  Password = "thay-bang-chuoi-ngau-nhien-dai"
  Maximum Concurrent Jobs = 1
}

Mật khẩu ở đây phải khớp với mật khẩu khai trong resource Director của File Daemon trên chính web01 (thư mục bareos-fd.d/director/). Hai đầu không khớp thì job sẽ lỗi xác thực ngay khi Director gọi sang.

FileSet: lấy gì, bỏ gì

# /etc/bareos/bareos-dir.d/fileset/web01-fs.conf
FileSet {
  Name = "web01-fs"
  Include {
    Options {
      Signature = XXH128
      Compression = LZ4
    }
    File = /etc
    File = /var/www
  }
  Exclude {
    File = /var/www/html/cache
    File = /var/www/html/tmp
  }
}

Signature là thuật toán băm dùng để kiểm tính toàn vẹn từng file. Compression = LZ4 bật nén ngay trên máy chủ nguồn, trước khi dữ liệu đi qua mạng. Nên bật nén từ bản Full đầu tiên. Nén không có tác dụng ngược với các bản đã ghi, và đổi tuỳ chọn trong FileSet sau này sẽ kéo theo một bản Full mới (xem phần bẫy bên dưới).

Schedule: khi nào chạy

# /etc/bareos/bareos-dir.d/schedule/lich-web.conf
Schedule {
  Name = "lich-web"
  Run = Level=Full on 1 at 21:00
  Run = Level=Incremental on 2-31 at 21:00
}

Hai dòng Run có tập ngày tách rời nhau: ngày 1 chỉ chạy Full, các ngày còn lại chạy Incremental. Chi tiết cú pháp và vì sao “tách rời” quan trọng là nội dung của bài 4.

Pool: ghi vào đâu, giữ bao lâu

# /etc/bareos/bareos-dir.d/pool/web.conf
Pool {
  Name = "web"
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 30 days
  Maximum Volume Bytes = 50G
  Maximum Volumes = 100
  Label Format = "web-"
}

Label Format cho phép Bareos tự tạo volume mới tên web-0001, web-0002… khi cần. Maximum Volumes là trần số volume của pool. Hai dòng này, nhân với nhau, gần như quyết định pool được phép chiếm bao nhiêu đĩa.

JobDefs và Job

# /etc/bareos/bareos-dir.d/jobdefs/web-mac-dinh.conf
JobDefs {
  Name = "web-mac-dinh"
  Type = Backup
  Level = Incremental
  Schedule = "lich-web"
  Storage = "File"
  Pool = "web"
  Messages = "Standard"
  Priority = 10
  Reschedule On Error = yes
  Reschedule Interval = 1 hour
  Reschedule Times = 2
}

# /etc/bareos/bareos-dir.d/job/backup-web01.conf
Job {
  Name = "backup-web01"
  JobDefs = "web-mac-dinh"
  Client = "web01-fd"
  FileSet = "web01-fs"
}

Ba dòng Reschedule giúp job tự thử lại sau một giờ nếu lỗi, tối đa hai lần. Kinh nghiệm cho thấy nhiều lỗi giờ cao điểm là lỗi nhất thời: máy chủ nguồn bận, mạng chập chờn. Tự thử lại giúp cảnh báo chỉ bắn khi job thua cả ba lượt, đỡ báo động giả.

Kiểm trước khi nạp

Đừng bao giờ reload ngay sau khi sửa file. Hãy để Director tự kiểm cú pháp và các tham chiếu trước:

# Kiểm toàn bộ cấu hình, chạy đúng quyền user bareos
sudo -u bareos bareos-dir -t

# Không in gì và thoát mã 0 nghĩa là cấu hình đọc được. Khi đó mới nạp:
echo "reload" | bconsole

# Xem Director hiểu Job ra sao sau khi gộp JobDefs
echo "show job=backup-web01" | bconsole

# Xem trước danh sách file sẽ lấy, chưa ghi gì
echo "estimate job=backup-web01 level=Full listing" | bconsole

bareos-dir -t bắt được lỗi cú pháp, resource trùng tên, và tham chiếu tới resource không tồn tại (ví dụ gõ nhầm Pool = "wbe"). Lệnh estimate … listing rất đáng dùng với FileSet mới: nó cho thấy thư mục cache đã bị loại thật hay chưa, trước khi tốn cả đêm backup.

Tuy vậy, -t chỉ kiểm được cấu hình có đọc được hay không. Nó không kiểm được cấu hình có đúng ý bạn hay không. Hai dòng Run trùng ngày, retention quá ngắn, FileSet quên mất thư mục dữ liệu — tất cả đều qua -t một cách vui vẻ.

Bẫy và bài học vận hành

Tên job là định danh của cả lịch sử

Catalog gắn toàn bộ lịch sử backup vào tên job. Khi Director quyết định lần Incremental tối nay lấy file nào, nó tìm lần chạy thành công gần nhất của đúng tên job đó. Hệ quả là đổi tên job tương đương mở một chuỗi backup mới:

• Lần chạy đầu tiên dưới tên mới không tìm thấy bản Full nào, nên tự nâng lên Full. Tốn thêm một bản Full ngoài kế hoạch.
• Lịch sử cũ vẫn nằm trong catalog nhưng dưới tên cũ. Công cụ báo cáo nào tra theo tên mới sẽ thấy máy chủ này “mới backup lần đầu”.
• Bản cũ vẫn chiếm đĩa cho tới khi hết retention, dù không ai còn nhìn thấy nó.

Vì thế, đừng đặt tên job theo thứ hay đổi: địa chỉ IP, cấu hình máy, tên khách hàng. Hãy đặt theo một ID ổn định của máy chủ nguồn, ví dụ /etc/machine-id hoặc UUID của máy chủ. Tên job trông sẽ kém thân thiện, như backup-3f2a9c…, nhưng không bao giờ phải đổi.

Khi đó cần thêm một bảng ánh xạ ID ↔ tên dễ đọc, lưu riêng trong một cơ sở dữ liệu hoặc file quản lý. Mọi báo cáo tra tên qua bảng này. Đừng tìm cách suy ngược tên máy chủ từ chuỗi tên job. Trong quá trình vận hành, đội kỹ thuật Cloudzone từng gặp đúng tình huống máy chủ nguồn đổi tên hàng loạt, và bảng ánh xạ riêng là thứ giữ cho lịch sử liền mạch.

Thêm một chi tiết nhỏ: tên máy chủ đôi khi có dấu cách hoặc ký tự lạ. Nếu buộc phải dùng tên làm tên job, hãy chuẩn hoá (thay dấu cách bằng _) và lưu cả hai dạng vào bảng ánh xạ.

Sửa FileSet cũng mở ra một bản Full

Mặc định Bareos coi FileSet là một phần của “chuỗi backup”. Khi nội dung Include thay đổi, lần chạy kế tiếp thường tự nâng lên Full. Điều này có lý: bản Incremental dựa trên một danh sách thư mục khác thì không ghép với bản Full cũ thành một bản khôi phục đầy đủ được.

Có tuỳ chọn Ignore FileSet Changes = yes để tắt hành vi này. Không nên bật nó như một mặc định cho mọi FileSet, vì nó tắt luôn lưới an toàn cho mọi thay đổi khác. Hợp lý hơn là chấp nhận một bản Full mỗi lần sửa FileSet, và gom các thay đổi lại để sửa một lần.

Tách file viết tay và file do công cụ sinh

Khi hệ thống lớn lên, gần như chắc chắn sẽ có script hoặc công cụ sinh cấu hình. Lúc đó, thư mục bareos-dir.d/job/ chứa lẫn file người viết tay và file máy sinh. Một vài quy ước giúp tránh việc công cụ ghi đè nhầm file người khác đang dùng:

• File do công cụ sinh mang một tiền tố riêng, và có dòng chú thích đầu file “file sinh tự động, đừng sửa tay”.
• Công cụ chỉ được sửa file có trong danh sách do chính nó tạo ra. Không đụng tới file nào khác, kể cả khi trùng tên.
• Không sửa các resource mặc định đi kèm gói cài đặt (DefaultJob, WeeklyCycle…). Cần khác thì tạo resource mới.

Luôn -t trước khi reload

Nếu cấu hình mới có lỗi, reload thường từ chối nạp và Director tiếp tục chạy với cấu hình cũ. Nhưng lúc khởi động lại dịch vụ, Director sẽ không lên nổi. Một file lỗi nằm im trong thư mục có thể chỉ lộ ra vào lần khởi động lại máy chủ backup kế tiếp, đúng lúc không ai nhớ đã sửa gì. Chạy bareos-dir -t sau mỗi lần sửa loại bỏ được rủi ro đó.

Khi bareos-dir -t báo “Too many open files”

Mỗi resource một file là cách tổ chức gọn, nhưng khi số job lên tới hàng nghìn thì số file cấu hình cũng lên hàng nghìn. Lúc đó, chạy bareos-dir -t từ một phiên SSH có thể thất bại ngay dù cấu hình hoàn toàn đúng:

Nguyên nhân không nằm ở Bareos mà ở giới hạn số file được mở cùng lúc. Phiên đăng nhập thường chỉ được mở 1.024 file, trong khi Director chạy dưới systemd được cấp giới hạn cao hơn nhiều — nên dịch vụ vẫn chạy bình thường, chỉ lệnh kiểm tra chạy tay là hỏng. Nguy hiểm ở chỗ mã thoát khác 0 trông y như cấu hình sai, và script tự động có thể từ chối một thay đổi hoàn toàn hợp lệ. Cách xử lý là nâng giới hạn ngay trong lệnh kiểm tra:

sudo -u bareos bash -c "ulimit -n 65536; bareos-dir -t"

Ảnh trên còn cho thấy một điều nữa: bareos-dir -t in cả cảnh báo (ở đây là từ khoá cũ JobRetention, FileRetention đã bị đánh dấu lỗi thời) mà vẫn thoát mã 0. Cảnh báo không chặn việc nạp cấu hình, nhưng nên dọn dần để bản nâng cấp sau không biến chúng thành lỗi.

Tóm tắt

• Cấu hình Director nằm trong /etc/bareos/bareos-dir.d/, mỗi resource một file, nối với nhau bằng Name.
• Job trỏ tới Client, FileSet, Schedule, Pool, Storage; JobDefs là khuôn mẫu để nhiều Job dùng chung.
• Pool quyết định retention và trần đĩa, không phải Job.
• Luôn chạy bareos-dir -t trước reload, và dùng estimate … listing để xem trước FileSet.
• Đặt tên job theo ID ổn định của máy chủ nguồn, giữ bảng ánh xạ ID ↔ tên riêng. Đổi tên job hay sửa FileSet đều tốn thêm một bản Full.

Bài sau: Full, Incremental hay Differential? Một phép chứng minh — vì sao không có cấu hình nào vừa tiết kiệm đĩa vừa khôi phục nhanh nhất, và cách viết Schedule để hai level không bao giờ chạy chồng lên nhau.

Bài viết thuộc chuỗi “Bareos từ cài đặt tới vận hành” của đội kỹ thuật Cloudzone.