Một phần quan trọng của việc ngăn chặn bất kỳ loại mất mát dữ liệu nào trong bất kỳ tình huống nào là có các chính sách sao lưu và phục hồi thích hợp. Nó cũng cần thiết để đảm bảo khôi phục dữ liệu tại bất kỳ thời điểm nào của vòng đời quy trình ứng dụng. Cả MySQL và MariaDB đều cung cấp giải pháp cho những trường hợp này. Bài viết này sẽ khám phá các tùy chọn và quy trình hiện có cũng như các tùy chọn sao lưu tiềm năng khác cho MySQL và MariaDB.
Chiến lược dự phòng
Vì dữ liệu là phần quan trọng nhất của bất kỳ ứng dụng nào, nên việc bảo vệ tính toàn vẹn của nó là điều quan trọng để tồn tại trong cuộc chiến tồn tại. Bất kỳ sự gián đoạn nào về khả năng truy cập hoặc tính toàn vẹn của dữ liệu trong bất kỳ thời điểm nào đều có thể gây hại nghiêm trọng cho ứng dụng và doanh nghiệp / dịch vụ mà nó đang cung cấp.
Để đảm bảo quy trình ứng dụng thành công và tính liên tục trong kinh doanh, bạn cần thực hiện các chính sách sao lưu và phục hồi phù hợp với các bản sao lưu hàng ngày, hàng tuần, hàng tháng và hàng năm. Các bản sao lưu như vậy sẽ chạy ở các giai đoạn quan trọng, chẳng hạn như:
- trước cửa sổ hàng loạt hàng ngày;
- trước khi nhập dữ liệu lớn;
- trước khi nâng cấp ứng dụng;
- sao lưu hàng tuần, hàng tháng và hàng năm để đáp ứng các yêu cầu quy định;
- hoặc bảo trì theo lịch hàng ngày / hàng tuần khác.
Công cụ sao lưu
MySQL và MariaDB cung cấp một số cách để thiết lập và thực hiện các kế hoạch sao lưu và phục hồi. Các phương pháp này bao gồm các bản sao lưu vật lý với MySQL’s Enterprise mysqlbackup tool , Công cụ dự phòng của MariaDB hoặc công cụ XtraBackup của Percona . Ngoài ra, các bản sao lưu hợp lý được tạo bằng công cụ mysqldump của Mysql có thể có ích. Một tùy chọn khác là khôi phục tại thời điểm với bin-log của cơ sở dữ liệu (nhật ký giao dịch) kết hợp với các công cụ được đề cập trước đó.
Bạn có thể kết hợp các phương pháp phù hợp vào chiến lược sao lưu của mình để tối đa hóa khả năng khôi phục cơ sở dữ liệu trong trường hợp thất bại hoặc thảm họa.
Lưu ý:Trong phiên bản MariaDB 10.4.6, mysqldump’s symlink được gọi là mariadb-dump . Trong các phiên bản sau, bao gồm cả 10.5.2, tên lại thay đổi - mysqldump đã trở thành liên kết biểu tượng .
Để minh họa các quy trình, tôi sẽ sử dụng công cụ mariabackup để tạo bản sao lưu vật lý. Chức năng cơ bản của công cụ cũng giống như trong các công cụ nói trên, mặc dù có một số khác biệt nhỏ dành riêng cho mỗi công cụ.
Sao lưu cơ sở dữ liệu vật lý
Sao lưu vật lý là bản sao lưu cấp tệp cung cấp cho bạn các phương pháp sao chép tệp nhanh chóng. Các bản sao lưu như vậy thích hợp hơn trong các tình huống khôi phục sau thảm họa, nhân bản cơ sở dữ liệu và / hoặc tạo cơ sở dữ liệu nô lệ.
Khi thực hiện sao lưu vật lý, bạn có thể chọn tạo bản sao lưu đầy đủ hoặc tăng dần. Các bản sao lưu đầy đủ bao gồm một bản sao lưu hoàn chỉnh của máy chủ cơ sở dữ liệu. Sao lưu tăng dần chỉ lưu các thay đổi từ bản sao lưu đầy đủ hoặc tăng dần.
Quan trọng:Kích thước của cơ sở dữ liệu quy định thời gian sao lưu. Vì lý do đó, một chiến lược tốt để sao lưu một cơ sở dữ liệu rất lớn có thể là kết hợp các bản sao lưu đầy đủ và gia tăng. Bằng cách này, bạn tiết kiệm cả không gian lưu trữ sao lưu và tổng thời gian sao lưu và phục hồi.
Một thời điểm khác mà bạn cần lưu ý là khi bạn khôi phục dữ liệu từ bản sao lưu vật lý, bạn phải dừng quy trình phiên bản cơ sở dữ liệu MySQL / MariaDB của mình cho đến khi hoàn tất các bước khôi phục cuối cùng.
Bạn có thể thực hiện một bản sao lưu vật lý đầy đủ đơn giản như sau:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220 \
--user=backupuser --password=backuppasswd
–target-dir tùy chọn cho công cụ sao lưu biết nơi đặt bản sao lưu.
Trong ví dụ này, tôi đã sắp xếp bản sao lưu của mình vào thư mục có tên DYYYYMMDD nơi mỗi bản sao lưu đầy đủ được lưu trữ (D là viết tắt của Daily). Khi làm như vậy, chúng tôi có một quá trình hành động dễ dàng để khôi phục cơ sở dữ liệu từ bản sao lưu được thực hiện vào một ngày cụ thể.
Ví dụ tiếp theo minh họa việc thực hiện sao lưu gia tăng đơn giản:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc1/ \
--incremental-basedir=/data/backups/mariadb/D20210220/ \
--user=backupuser --password=backuppasswd
Bản sao lưu gia tăng tiếp theo sẽ trông dọc theo các dòng sau:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc2/ \
--incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
--user=backupuser --password=backuppasswd
–incremental-basedir tùy chọn hướng dẫn công cụ sao lưu sử dụng bản sao lưu đầy đủ hoặc tăng dần đã lấy trước đó làm điểm bắt đầu trong việc xây dựng các tệp delta gia tăng cho bản sao lưu hiện tại. Bằng cách này, nó xây dựng một chuỗi gồm một bản sao lưu đầy đủ với các bản sao lưu gia tăng tiếp theo. Cùng nhau, chúng tạo thành một bản sao lưu duy nhất để khôi phục khi cần thiết.
Bây giờ, chúng ta hãy tìm hiểu tên của tệp cơ sở dữ liệu vật lý mà trong đó tất cả dữ liệu thư mục được lưu trữ. Cơ sở dữ liệu nằm trên Domain Controllers là một Active Directory. Thư mục này được sử dụng để quản lý người dùng, dữ liệu, v.v. Cốt lõi của Active Directory là tệp cơ sở dữ liệu NTDS.DIT bao gồm liên kết, bộ mô tả bảo mật và bảng dữ liệu. Tất cả dữ liệu thư mục được giữ trong tệp cơ sở dữ liệu vật lý này.
Cần phải phân biệt giữa tệp vật lý và tệp logic. Dữ liệu hệ thống thực tế nằm trong các tệp vật lý, trong khi các tệp logic chứa mô tả về các bản ghi được lưu trữ trong tệp vật lý.
Nhiệm vụ khôi phục cơ sở dữ liệu MySQL từ các tệp vật lý đôi khi có thể khó khăn. mysqldump lệnh có thể hữu ích trong trường hợp này. Chúng tôi sẽ đề cập sâu hơn về chủ đề này.
Sao lưu cơ sở dữ liệu logic
Các bản sao lưu logic được tạo bằng mysqldump dụng cụ. Phương pháp sao lưu này linh hoạt hơn so với sao lưu vật lý. Nó bao gồm tất cả các câu lệnh SQL DML và / hoặc DDL cần thiết để tạo thành một bản sao lưu nhất quán, kết hợp tất cả dữ liệu đã cam kết và các thay đổi được thực hiện trước và trong khi sao lưu. Nếu bạn muốn biết thêm về cách sao lưu và khôi phục tất cả cơ sở dữ liệu, bạn có thể đọc bài viết này.
Bản sao lưu hợp lý có thể là một tệp duy nhất hoặc nhiều tệp (được tạo bằng một tập lệnh cụ thể). Hơn nữa, bạn có thể khôi phục cấu trúc và / hoặc dữ liệu mà không cần tắt phiên bản MySQL / MariaDB (quy trình) của bạn. Theo đó, sao lưu lôgic được thực hiện trên cơ sở dữ liệu và / hoặc cấp bảng, trong khi sao lưu vật lý ở cấp hệ thống tệp (thư mục và tệp).
Cũng lưu ý rằng các bản sao lưu lôgic chỉ là các hình ảnh sao lưu đầy đủ của các cơ sở dữ liệu và / hoặc các bảng dự kiến.
Tạo một bản sao lưu hợp lý của toàn bộ phiên bản MySQL / MariaDB như sau:
mysqldump --all-databases --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql
Lưu ý rằng sao lưu vật lý và sao lưu lôgic được phân biệt cụ thể trong hệ thống tệp cho mục đích quản lý sao lưu.
Không giống như ví dụ trước, một bản sao lưu hợp lý của một cơ sở dữ liệu đơn lẻ (lược đồ) được tạo theo cách sau:
mysqldump empdb --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql
Cuối cùng, để tạo bản sao lưu hợp lý của một bảng trong cơ sở dữ liệu, hãy thêm tên của bảng sau cơ sở dữ liệu:
mysqldump empdb departments --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql
Khi bạn cần chỉnh sửa và thêm các câu lệnh DROP DATABASE hoặc DROP TABLE vào kịch bản khôi phục, việc làm việc với các tệp sao lưu lớn có thể gây ra các hiệu ứng khó chịu đối với các trình soạn thảo văn bản đến mức nghẹt thở.
Trong những trường hợp như vậy, hãy xem xét thêm các tùy chọn khác, chẳng hạn như –add-drop-database và / hoặc –add-drop-table để đưa các câu lệnh DROP này vào bản sao lưu. Trong các trường hợp khác, bạn có thể muốn loại trừ những câu lệnh này và thay thế chúng bằng –skip-add-drop-table tùy chọn cho lệnh.
Tuy nhiên, bạn cũng có thể tạo bản sao lưu chỉ dữ liệu hoặc chỉ DDL bằng cách sử dụng –no-create-info hoặc – không có dữ liệu tùy chọn. Sao lưu cấu trúc và dữ liệu riêng biệt có thể là một lựa chọn tốt trong một số trường hợp khôi phục, đặc biệt khi bạn chỉ cần cấu trúc DDL để tạo cơ sở dữ liệu nhân bản trống và / hoặc các bảng của nó.
Sao lưu cơ sở dữ liệu bằng cách sử dụng ảnh chụp nhanh trên đĩa
Khi dữ liệu phát triển, có thể cần thiết phải tổ chức nó trên một số đĩa và / hoặc hệ thống tệp. Bên cạnh các lý do về hiệu suất, vì I / O được phân phối trên nhiều đĩa / hệ thống tệp, bạn phải đảm bảo rằng các chiến lược sao lưu và phục hồi hiệu quả bao gồm khả năng chụp nhanh hệ thống tệp và đĩa.
Bắt đầu bằng cách thiết kế và xây dựng bố cục hệ thống tệp nơi từng cơ sở dữ liệu, nhóm bảng và chỉ mục nằm. Sau đó, sắp xếp các bảng của bạn và cấu hình hệ thống cơ sở dữ liệu. Tất cả chúng phải nằm trong một thư mục duy nhất:
innodb_home_dir = /<path where your InnoDB tables will reside>Hoặc, bạn có thể sử dụng DATA_DIRECTORY và INDEX_DIRECTORY các tùy chọn trong CREATE bảng sao kê để phân phối chúng riêng biệt đến các vị trí hệ thống tệp khác nhau.
Đối với InnoDB, hãy đảm bảo sử dụng file_per_table =ON (mặc định BẬT trong các phiên bản mới nhất). Chọn đường dẫn cho các bảng InnoDB một cách cẩn thận khi bạn tạo chúng. Không thể thay đổi đường dẫn nếu không xóa và tạo lại bảng.
Sẽ rất hữu ích nếu có hệ thống tệp thích hợp với khả năng chụp nhanh tích hợp, ví dụ:XFS và ZFS trên Linux. Lưu ý rằng việc tạo bản sao lưu ảnh chụp nhanh tương tự như tạo bản sao lưu vật lý, nhưng nó có những đặc điểm cụ thể. Nó yêu cầu dừng quá trình viết ( FLUSH với READ LOCK hoặc tương tự - xem GIAI ĐOẠN DỰ PHÒNG trong tài liệu trực tuyến MariaDB) trước khi chụp nhanh và phát hành LOCKS ngay sau khi hoàn thành ảnh chụp nhanh. Cần đảm bảo tính nhất quán của dữ liệu.
Bạn nên xem xét và sử dụng các bản sao lưu ảnh chụp nhanh trong các tình huống khôi phục sau thảm họa. Tuy nhiên, chúng cũng thích hợp để nhân bản các phiên bản cơ sở dữ liệu.
Chiến lược khôi phục
Khôi phục từ bản sao lưu vật lý
Trước đây, chúng tôi đã mô tả các bước sao lưu vật lý. Bằng cách này, bạn có thể tạo một chuỗi các bản sao lưu đầy đủ hoặc một chuỗi các bản sao lưu đầy đủ và tăng dần. Tùy chọn thứ hai có nghĩa là một bản sao lưu đầy đủ theo sau một bản sao lưu gia tăng tiếp theo là điểm 0 nếu xảy ra lỗi.
Ví dụ:một DBA thực hiện các bản sao lưu đầy đủ vào Chủ nhật và sao lưu tăng dần vào các ngày khác. Lỗi xảy ra sau khi thực hiện một bản sao lưu gia tăng vào thứ Tư. Do đó, họ cần khôi phục lại cơ sở dữ liệu. Trong những trường hợp như vậy, DBA của chúng tôi phải sử dụng bản sao lưu đầy đủ được thực hiện vào Chủ nhật và các bản sao lưu gia tăng được thực hiện vào Thứ Hai, Thứ Ba và Thứ Tư. Nếu có bản sao lưu đầy đủ hàng ngày, thì chỉ cần khôi phục bản sao lưu vào thứ Tư là đủ.
Để khôi phục bản sao lưu “gần nhất” sau khi bị lỗi, cho dù đó là bản sao lưu toàn bộ hay tăng dần, bạn cần đảm bảo rằng TẤT CẢ các tệp sao lưu đều nhất quán tại thời điểm với thời điểm kết thúc sao lưu gần nhất. Nếu không, công cụ InnoDB sẽ từ chối dữ liệu bằng cách coi nó bị hỏng.
Một điểm quan trọng khác là, khi bạn chuẩn bị sao lưu, hãy sao chép các bản sao lưu đầy đủ có liên quan sang một vị trí khác trước khi áp dụng các bước để đảm bảo tính nhất quán theo thời gian. Bằng cách này, bạn giữ nguyên trạng thái sao lưu ban đầu, có thể hữu ích sau này. Tôi thực sự khuyên bạn nên sử dụng cách tiếp cận này.
Để chuẩn bị một bản sao lưu đầy đủ, hãy chọn một bản sao lưu gần nhất với sự cố, sao chép nó vào vị trí ưu tiên và thực hiện lệnh sau:
mariabackup --prepare \
--target-dir=data/backups/mariadb/COPY_D20210220
Để khôi phục về bản sao lưu gia tăng gần nhất, hãy chuẩn bị một bản sao của bản sao lưu đầy đủ gần nhất và thêm tất cả các bản sao lưu gia tăng có liên quan trong một đơn đặt hàng tiếp theo . Hình ảnh cơ sở dữ liệu được khôi phục sẽ như sau:
Chúng tôi đạt được điều này bằng cách thực hiện chuẩn bị lệnh cho mỗi bản sao lưu gia tăng như được hiển thị bên dưới:
mariabackup --prepare \
--target-dir=/data/backups/mariadb/COPY_D20210220 \
--incremental-dir=/data/backups/mariadb/D20210220_INC#
Sau khi chuẩn bị bản sao lưu, chúng ta phải tắt phiên bản cơ sở dữ liệu (tiến trình). Ngoài ra, chúng tôi phải làm trống thư mục cơ sở dữ liệu trước khi kết thúc quá trình khôi phục. Bạn có thể ra lệnh bằng –copy-back tùy chọn
mariabackup --copy-back \
--target-dir=data/backups/mariadb/COPY_D20210220
hoặc với –move-back tùy chọn:
mariabackup --move-back \
--target-dir=data/backups/mariadb/COPY_D20210220
Lệnh sau sẽ di chuyển thư mục đã sao chép vào thư mục cơ sở dữ liệu. Sao chép bản sao lưu gốc sang một vị trí khác là một lựa chọn khôn ngoan. Nếu không, bản sao lưu sẽ bị mất và không thể sử dụng nó cho các tình huống và tình huống khác.
Bước cuối cùng trước khi bắt đầu phiên bản cơ sở dữ liệu là điều chỉnh quyền sở hữu của các tệp để khớp với người dùng và nhóm của chủ sở hữu quy trình. Điển hình là MySQL.
Khôi phục từ các bản sao lưu lôgic
Thông thường, chúng tôi bỏ qua một điểm quan trọng khi khôi phục cơ sở dữ liệu và / hoặc bảng bằng cách sử dụng sao lưu lôgic. Điểm này đang đặt max_allowed_packet kích thước của phiên (có thể khôn ngoan hơn nếu đặt nó trên toàn cầu) thành giá trị tối đa là 1073741824. Cần đảm bảo rằng bộ đệm lớn và câu lệnh INSERT phù hợp với một gói duy nhất giữa máy khách và máy chủ. Điều này sẽ làm giảm thời gian khôi phục.
Một khía cạnh quan trọng khác khi tạo bản sao lưu là bao gồm hoặc loại trừ các câu lệnh DROP như đã đề cập trước đó. Chúng tôi cần nó để đảm bảo chạy quá trình khôi phục sao lưu suôn sẻ nhất có thể. Với lưu ý đó, hãy sử dụng đoạn mã dưới đây để thực hiện khôi phục sao lưu:
mysql -u backupuser -p backuppasswd < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlNếu bạn không có bất kỳ cơ sở dữ liệu nào được bao gồm trong bản sao lưu, cũng như với các bản sao lưu cơ sở dữ liệu riêng lẻ hoặc bạn cần chuyển hướng khôi phục đến cơ sở dữ liệu khác, hãy sử dụng mã khác:
mysql -u backupuser -p backuppasswd newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlKhôi phục với ảnh chụp nhanh đĩa
Để khôi phục từ ảnh chụp nhanh đĩa luôn luôn bắt đầu bằng đảm bảo rằng hệ thống cơ sở dữ liệu đã ngừng hoạt động trước khi quá trình khôi phục được thực hiện . Bất kỳ nỗ lực nào để khôi phục cơ sở dữ liệu trực tiếp bằng cách sử dụng ảnh chụp nhanh đĩa sẽ dẫn đến sự không nhất quán về dữ liệu và nhiều khả năng là hỏng dữ liệu.
Khôi phục tại chỗ
Phục hồi điểm trong thời gian (PITR), như tên của nó, là một phương pháp để khôi phục cơ sở dữ liệu và bảng gần với thời điểm trước khi bị lỗi. Hoặc, nếu quy trình hàng ngày không thành công và cần được thực hiện lại, bạn cũng có tùy chọn duy nhất - thực hiện khôi phục sao lưu PITR.
Điều quan trọng là bật bin-log của cơ sở dữ liệu và đặt định dạng bin-log thành ghi nhật ký Dựa trên báo cáo, Dựa trên hàng hoặc Hỗn hợp, tùy thuộc vào loại khối lượng công việc mà cơ sở dữ liệu của bạn đang chạy. Hơn nữa, bạn có thể cần bật tính năng nén bằng cách sử dụng log_bin_compress =BẬT (TẮT mặc định) để tiết kiệm dung lượng đĩa.
Vì bin-log là một nhật ký giao dịch và được tạo theo một trình tự, điều quan trọng là phải tạo một bản sao lưu của tất cả các tệp nhật ký. Đối với quy trình PITR, điều đó không thể mà không cần logfiles. Bên cạnh đó, bảo trì bin-log và vòng đời phải tuân theo vòng đời của bất kỳ bản sao lưu đầy đủ và gia tăng nào. Do đó, hãy đảm bảo chỉ xóa các bản ghi cũ hơn bản sao lưu cũ nhất trong chính sách sao lưu.
Bạn có thể xóa nhật ký nhị phân theo hai cách. Đầu tiên, đó là bằng cách khai báo tên bin-log gần nhất cho bản sao lưu cũ nhất như được hiển thị trong lệnh xóa dưới đây:
PURGE BINARY LOGS TO 'mariadb-bin.000063';Thứ hai, đó là bằng cách khai báo ngày của bản sao lưu cũ nhất được giữ trong lệnh thanh lọc:
PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';Để chuẩn bị cho việc khôi phục, chúng ta cần truy xuất tất cả các câu lệnh cần thiết để phát lại đúng thời điểm cần thiết. Thu thập tất cả nhật ký bin có sẵn từ thời điểm bắt đầu sao lưu đến thời điểm bạn đang khôi phục.
Bắt đầu bằng cách kiểm tra danh sách nhật ký từ thời điểm kết thúc sao lưu đến thời điểm PITR:
mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql
Sau đó, kiểm tra các tệp tạm thời để tìm vị trí nhật ký chính xác mà bạn muốn áp dụng và sử dụng. Đây là – vị trí bắt đầu và –stop-position đặt các vị trí chính xác trong lệnh và thực thi lại mysqlbinlog lệnh:
mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql
Tại thời điểm này, quá trình khôi phục đã bắt đầu. Nó sử dụng các bản sao lưu vật lý hoặc logic, đầy đủ hoặc tăng dần.
Hoàn tất quá trình khôi phục bằng cách áp dụng final_tempional_PITR_file.sql sử dụng máy khách MySQL như được hiển thị bên dưới:
mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sqlChúng tôi đã hoàn thành việc khôi phục PITR bằng cách khôi phục các giao dịch sao lưu và phát lại từ nhật ký đến thời điểm gần nhất cho đến thời điểm xảy ra lỗi.
Bàn làm việc
Để thiết kế và phát triển cơ sở dữ liệu, kiểm tra và bảo trì trong MySQL và MariaDB, chúng ta có thể sử dụng Workbench ứng dụng Windows. Nó cũng hoạt động trên Linux. Với ứng dụng này, người dùng có thể thiết kế cơ sở dữ liệu, xem và thay đổi dữ liệu meta, truyền dữ liệu và dữ liệu meta, v.v. Cần thêm rằng có thể sử dụng dbForge Studio cho MySQL thay vì Workbench.
Kết luận
Nhìn chung, chúng ta đã thảo luận ngắn gọn và minh họa các kỹ thuật sao lưu và phục hồi cơ sở dữ liệu bằng các công cụ và phương pháp có sẵn trong MySQL và MariaDB.
Để khôi phục thành công hệ thống cơ sở dữ liệu từ bất kỳ lỗi nào, chúng tôi phải thực hiện cả sao lưu vật lý và logic các phương pháp được đề cập ở trên vào các chính sách và kế hoạch, từ toàn bộ hệ thống xuống các bảng riêng lẻ.
Để thực hiện PITR thành công, chúng tôi cần kích hoạt bin-log và nhu cầu quản lý nhật ký thích hợp tại chỗ.
Tuy nhiên, chỉ sử dụng một phương pháp sao lưu và thiếu nhật ký bin sẽ là cách tiếp cận sai lầm. Điều này có thể dẫn đến mất dữ liệu và làm tổn hại đến tính liên tục kinh doanh của ứng dụng của bạn. Do đó, hãy kết hợp các phương pháp khác nhau và luôn đưa tệp nhật ký vào chính sách sao lưu và khôi phục!
