Ưu Đãi Khi Mua Hosting
Mã giảm giá 10% : HOSTING1205
Muốn cron sao lưu MySQL chạy đúng giờ, hãy xác định múi giờ mà cron sử dụng trước khi đặt lịch. Đổi giờ trong ứng dụng hoặc trong MySQL không đồng nghĩa lịch cron sẽ đổi theo. Sau đó, cần kiểm tra lần chạy thực tế, ngăn tác vụ chạy chồng và xác nhận bản sao lưu có thể phục hồi.
Hướng dẫn dưới đây dành cho người quản trị website hoặc VPS Linux muốn sao lưu theo giờ Việt Nam, đặc biệt khi máy chủ đang dùng UTC. Các tên cơ sở dữ liệu và đường dẫn trong ví dụ đều là minh họa, cần thay theo môi trường thực tế.
Một website có thể đồng thời dùng nhiều múi giờ. Bạn cần phân biệt vai trò của từng lớp để tránh sửa đúng giờ hiển thị nhưng sai lịch chạy.
Trên máy chủ Linux dùng systemd, kiểm tra bằng các lệnh sau. Nếu môi trường không có timedatectl, dùng date và công cụ quản trị tương ứng.
date '+%Y-%m-%d %H:%M:%S %Z %z'
timedatectl status
crontab -lGhi lại múi giờ, độ lệch UTC và trạng thái đồng bộ đồng hồ. Múi giờ đúng nhưng đồng hồ hệ thống sai vẫn khiến tác vụ chạy lệch thời điểm thực tế.
Nếu cron dùng UTC, 02:00 tại Việt Nam tương ứng 19:00 UTC ngày hôm trước. Lịch sao lưu hằng ngày lúc 02:00 giờ Việt Nam có thể biểu diễn như sau trong crontab của người dùng:
0 19 * * * /opt/backup/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1Ví dụ giả định bạn đã tạo chương trình sao lưu tại đường dẫn trên và tài khoản chạy cron có quyền ghi log. Không sao chép nguyên đường dẫn nếu máy chủ chưa có các tệp này.
Với lịch theo tuần, phải quy đổi cả ngày. Chẳng hạn, 02:00 thứ Hai tại Việt Nam là 19:00 Chủ nhật theo UTC. Nếu chỉ đổi giờ mà giữ thứ Hai, bản sao lưu sẽ chạy muộn một ngày so với mong muốn.
Một số bản cron hỗ trợ biến CRON_TZ. Khi tài liệu của bản cron đang cài xác nhận có hỗ trợ, bạn có thể khai báo:
CRON_TZ=Asia/Ho_Chi_Minh
0 2 * * * /opt/backup/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1Không mặc định mọi môi trường đều hiểu cấu hình này. Đặt TZ cho tiến trình cũng không bảo đảm bộ lập lịch dùng múi giờ đó để xét giờ chạy. Với hosting có bảng điều khiển, hãy xác nhận múi giờ của tính năng cron với nhà cung cấp.
Nếu máy chủ được quản trị thống nhất theo giờ Việt Nam, bạn có thể cân nhắc đổi múi giờ hệ thống. Tuy nhiên, thay đổi này có thể ảnh hưởng các tác vụ khác và cách đọc log. Cần rà soát toàn bộ lịch, kiểm tra hành vi của dịch vụ cron sau thay đổi và theo dõi lần chạy tiếp theo.
Không nên chọn giờ sao lưu chỉ vì đó là nửa đêm. Hãy xem lúc nào website ít ghi dữ liệu, ít nhập đơn hàng và không trùng tác vụ nặng như xuất báo cáo. Nếu phục vụ nhiều quốc gia, giờ ít tải có thể không trùng ban đêm tại Việt Nam.
Ví dụ giả định, website ít đơn ban đêm và chấp nhận mất tối đa một ngày dữ liệu có thể bắt đầu với lịch hằng ngày. Nếu yêu cầu phục hồi chặt hơn, cần xem xét sao lưu thường xuyên hơn hoặc phương án phục hồi theo thời điểm bằng binary log, thay vì chỉ đổi giờ cron.
Cron thường có môi trường tối giản, khác phiên SSH tương tác. Vì vậy, hãy dùng đường dẫn tuyệt đối, khai báo rõ thư mục làm việc và thử lệnh bằng đúng tài khoản chạy cron.
Với cơ sở dữ liệu chủ yếu dùng InnoDB, lệnh minh họa sau tạo bản xuất logic:
/usr/bin/mysqldump --defaults-extra-file=/etc/mysql/backup.cnf --single-transaction --quick ten_csdl > /duong-dan-bao-mat/backup.sqlTệp cấu hình đăng nhập phải có quyền truy cập hạn chế; không đưa mật khẩu vào crontab. Kiểm tra đường dẫn công cụ trên máy trước khi dùng. --single-transaction phù hợp để lấy dữ liệu nhất quán của bảng giao dịch như InnoDB, nhưng không bảo đảm tương tự cho bảng không hỗ trợ giao dịch. Tránh thay đổi cấu trúc bảng trong lúc xuất dữ liệu.
Tác vụ hoàn chỉnh nên ghi vào tệp tạm, kiểm tra mã thoát rồi mới đổi sang tên bản sao lưu chính thức. Nếu cần lưu procedure, function hoặc event, hãy kiểm tra thêm tùy chọn xuất và quyền tương ứng. Không xóa bản cũ trước khi xác nhận bản mới thành công.
Nếu lần sao lưu trước chưa xong, lần tiếp theo có thể tranh chấp tài nguyên hoặc ghi đè tệp. Trên Linux có tiện ích flock, có thể dùng khóa không chờ:
0 19 * * * /usr/bin/flock -n /duong-dan-khoa/mysql-backup.lock /opt/backup/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1Đường dẫn khóa phải tồn tại ở thư mục phù hợp và có quyền truy cập đúng. Cần ghi nhận trường hợp không lấy được khóa để phân biệt lần bị bỏ qua với lần thành công.
Cron truyền thống thường không tự chạy bù khi máy chủ tắt đúng giờ hẹn. Nếu cần chạy bù, hãy chọn cơ chế lập lịch có hỗ trợ, chẳng hạn systemd timer được cấu hình phù hợp. Với múi giờ có giờ mùa hè, thời điểm chuyển giờ có thể gây bỏ hoặc lặp lịch tùy bản cron; dùng UTC giúp tránh sự thay đổi theo mùa này.
Sau khi lưu lịch, hãy đặt một tác vụ kiểm tra ngắn ghi thời gian ra tệp rồi gỡ nó sau khi xác nhận. Nếu viết lệnh date trực tiếp trong crontab, lưu ý ký tự % có ý nghĩa đặc biệt trong nhiều bản cron và cần được xử lý đúng.
Các lỗi thường gặp gồm dùng sai crontab, thiếu quyền ghi thư mục, lệnh không nằm trong PATH, đầy đĩa hoặc lỗi xác thực MySQL. Crontab của người dùng có năm trường thời gian rồi đến lệnh; cấu hình hệ thống như /etc/crontab còn có trường người dùng. Nhầm hai định dạng có thể khiến tác vụ không chạy.
Không. Hãy sửa hoặc quy đổi lịch tại bộ lập lịch. Múi giờ MySQL phục vụ xử lý thời gian trong cơ sở dữ liệu.
Chưa chắc. Tiến trình có thể đặt tên theo UTC trong khi bạn đối chiếu theo giờ Việt Nam. Nên thống nhất quy ước tên tệp và ghi thời gian kèm độ lệch UTC trong log.
Chưa. Tệp có thể rỗng hoặc chỉ chứa một phần dữ liệu. Cần kiểm tra mã thoát và phục hồi thử để đánh giá khả năng sử dụng.
Hãy ghi rõ giờ mong muốn, múi giờ cron, giờ quy đổi và tài khoản thực thi; sau đó chạy thử toàn bộ quy trình, kể cả phục hồi. Nếu cần chọn VPS hoặc hosting cho tác vụ này, bạn có thể tham khảo danh mục liên quan tại sieuthicode.com và xác nhận trước tài nguyên, quyền chạy cron, công cụ MySQL, bảo mật, điều kiện sử dụng và hỗ trợ. Ưu tiên môi trường cho phép kiểm thử tải sao lưu thay vì chỉ chọn theo dung lượng lưu trữ.
