Khi bạn sử dụng T-SQL để sao lưu Transaction Log bằng lệnh BACKUP LOG, có thể xuất hiện lỗi như bên dưới:

Nguyên nhân

Lỗi này là do database có giá trị Recovery model là Simple. Khi Recovery model là Simple, SQL Server không cho phép sao lưu Transaction Log.

Cách khắc phục

Để có thể sao lưu Transaction Log, bạn cần thay đổi Recovery model thành Full hoặc Bulk-Logged. Bạn tiến hành thay đổi này theo hướng dẫn sau:

A – Sử dụng SQL Server Management Studio

• Chọn database cần thay đổi, right-click và chọn Properties.
  
• Trong cửa sổ Properties của database, chọn Options. Ở mục Recovery model, thay đổi giá trị từ Simple thành Full hoặc Bulk-Logged.
  
• Click OK để lưu.

B – Sử dụng dòng lệnh T-SQL

Để thay đổi giá trị Recovery model bằng T-SQL, bạn sử dụng lệnh sau:

# Free ebook: 8 lưu ý quan trọng khi sao lưu & phục hồi SQL Server

Kinh nghiệm giúp bảo vệ an toàn database SQL Server

Ebook chia sẻ những lưu ý quan trọng trong quá trình sao lưu và phục hồi SQL Server. Áp dụng các lưu ý có thể giúp bạn nâng cao đáng kể tính an toàn và khả năng phục hồi khi sự cố xảy ra với database SQL Server.

Download Now ››

The post Lỗi sao lưu Transaction Log trong SQL Server appeared first on zBackup.vn | Sao lưu mô hình Hybrid Backup.

Bản sao lưu sẽ kém an toàn nếu không đảm bảo tính chất offsite – nghĩa là lưu trữ cách xa dữ liệu gốc. Bởi bạn không thể biết trước sự cố gì sẽ xảy ra trong tương lai. Nếu là sự cố hư ổ cứng, nhân viên xóa nhầm hay virus phá hoại, bạn vẫn an toàn với bản sao lưu onsite. Nhưng nếu là cháy nổ, thiên tai, trộm cắp, kẻ xấu phá hoại, bạn chắc chắn gặp rắc rối to.

Hãy nhìn lại câu chuyện phá hoại nghiêm trọng trong đợt biểu tình phản đối giàn khoan Hải Dương 981 vào tháng 05/2014 tại Bình Dương, Đồng Nai, TP.HCM và nhiều tỉnh/thành khác. Nhiều doanh nghiệp hư hỏng dữ liệu nặng nề, thậm chí mất sạch dữ liệu khi cả server lẫn thiết bị sao lưu NAS, Tape đều bị đập phá, trộm cắp. Rõ ràng, khó có thể dự đoán được chuyện gì sẽ xảy ra. Thế nên, điều quan trọng là luôn sẵn sàng cho tình huống xấu nhất. Với hệ thống CNTT, sao lưu offsite chính là phương án mang đến sự sẵn sàng này.

Thực tế, doanh nghiệp bạn không cần phải có các Data Center cách xa nhau mới có thể sao lưu offsite. Với một ngân sách CNTT hạn hẹp, bạn vẫn có thể đảm bảo sao lưu offsite bằng 3 phương án sao lưu sau:

• Sao lưu bằng Tape
• Sao lưu sang DR Site
• Sử dụng dịch vụ Cloud Backup

1. Sao lưu bằng Tape

Với lịch sử hơn 50 năm, Tape đã quá cũ và đang dần được thay thế. Tuy nhiên, vẫn còn khá lâu để Tape kết thúc vai trò của mình. Tính linh hoạt và chi phí thấp giúp Tape vẫn được sử dụng ở nhiều doanh nghiệp. Điều quan trọng, bản thân Tape không đảm bảo tính chất offsite. Nên bạn cần tiến hành việc này một cách thủ công.

Ở nước ngoài, công tác lưu trữ Tape offsite có thể thuê ngoài một đơn vị cung cấp dịch vụ. Nhưng tại Việt Nam chưa có một nhà cung cấp như vậy. Do đó, đa phần người IT phải tự mình tiến hành thao tác lưu trữ offsite này. Cũng vì sự bất tiện, tốn nhiều thời gian như vậy nên thường công tác này rất ít được đảm bảo định kỳ.

Hiện tại, Tape đang dần được thay thế bởi nó mang nhiều điểm yếu khó khắc phục, không còn đáp ứng được yêu cầu sao lưu và phục hồi của doanh nghiệp (ngoại trừ các doanh nghiệp lớn cần sao lưu lượng dữ liệu hàng chục TB):

• Cài đặt, cấu hình, quản trị phức tạp
• Quá trình lưu trữ offsite phải tiến hành thủ công
• Khó khắc phục khi gặp lỗi thiết bị, lỗi phần mềm
• Phục hồi đòi hỏi nhiều thao tác, mất nhiều thời gian
• Khó tiến hành testing phục hồi định kỳ
• Phục thuộc lớn vào hỗ trợ của HĐH, phần mềm sao lưu

2. Sao lưu sang DR Site

Một lựa chọn khác cho những doanh nghiệp có chi nhánh, văn phòng, nhà máy cách xa trụ sở chính. Bạn có thể biến nơi này thành DR Site với hệ thống Backup Server hoàn chỉnh hoặc đơn giản chỉ trang bị một thiết bị NAS để lưu trữ dữ liệu sao lưu từ các server ở trụ sở chính.

Nếu công ty không có một địa điểm như vậy, bạn có thể thuê Data Center của nhà cung cấp dịch vụ để triển khai DR Site. Có thể thuê Colocation để đặt thiết bị hoặc thuê Dedicated Server để thiết lập Backup Server.

Tuy nhiên, phương án này lại gây nhiều phiền phức trong quản lý hệ thống sao lưu ở DR Site. Bởi cho dù có DR Site riêng hay thuê từ nhà cung cấp, bạn vẫn phải quản trị toàn bộ hệ thống sao lưu. Mà bạn hiểu rất rõ, rắc rối thường xảy ra nhất với sao lưu là vấn đề con người. Bởi đây là công tác nhàm chán nhất với người IT. Việc quản trị thường không được đảm bảo cho đến lúc…sự cố xảy ra.

Một số điểm yếu dễ thấy ở phương án này là:

• Đầu tư (hoặc thuê) hệ thống DR Site
• Cài đặt, thiết lập hệ thống sao lưu
• Theo dõi, quản lý sao lưu hàng ngày

3. Sử dụng dịch vụ Cloud Backup

Cũng như các dịch vụ Cloud Computing khác, Cloud Backup đang là xu hướng, là lựa chọn của doanh nghiệp lẫn người IT. Với đường truyền Internet ngày càng tốt hơn, giá thành dịch vụ ngày càng giảm, Cloud Backup được lựa chọn để thay thế Tape Backup, HDD Backup,… trong sao lưu offsite. Đặc biệt, Cloud Backup rất phù hợp với doanh nghiệp cần sao lưu lượng dữ liệu vài TB trở lại.

Với Cloud Backup, toàn bộ hệ thống sao lưu là trong suốt với doanh nghiệp bạn. Bởi nhà cung cấp sẽ chịu toàn bộ trách nhiệm đầu tư, vận hành, quản trị hệ thống để đảm bảo chất lượng dịch vụ theo cam kết. Bạn chỉ việc sử dụng phần mềm với đầy đủ các tính năng tích hợp ứng dụng, sao lưu tự động, mã hóa dữ liệu,… Đặc biệt, Cloud Backup cực kỳ thuận tiện khi cần phục hồi.

Cụ thể, Cloud Backup khắc phục nhiều điểm yếu của các phương án sao lưu truyền thống, mang đến cho bạn những lợi ích sau:

• Lưu trữ offsite cách xa văn phòng công ty bạn
• Quá trình sao lưu hoàn toàn tự động
• Tích hợp sẵn hầu hết ứng dụng quan trọng
• Mã hóa giúp bảo mật dữ liệu tuyệt đối
• Môi trường Data Center tiêu chuẩn, thiết bị lưu trữ cao cấp
• Phục hồi nhanh chóng, thuận tiện
• Dễ dàng tiến hành testing phục hồi định kỳ
• Không cần đầu tư thiết bị, phần mềm
• Hầu như không phải quản lý, vận hành

zBackup | Dịch vụ sao lưu dữ liệu mô hình Hybrid Backup

Mang đến cho doanh nghiệp bạn một giải pháp sao lưu toàn diện, bảo mật và hiệu năng:

• Sao lưu Local vào External HDD / NAS Device
• Sao lưu Offsite về hệ thống zBackup
• Sao lưu vào Google Drive, Dropbox, Azure, AWS,…
• Hỗ trợ File, AD, SQL Server, Exchange Server
• Hỗ trợ Oracle, MySQL, VMware, Hyper-V
• Sao lưu tự động theo lịch và thời gian thực
• Mã hóa 256-bit AES & SSL
• DR Ready giúp sẵn sàng thảm họa

Xem mô hình Hybrid Backup ››

The post 3 phương án sao lưu offsite phổ biến nhất appeared first on zBackup.vn | Sao lưu mô hình Hybrid Backup.

Tất nhiên, điều kiện đặt ra là database chỉ bị lỗi Data file (.MDF), còn Log file (.LDF) vẫn sử dụng được.

Một ví dụ

Bạn có database Accounting được sao lưu theo chính sách sau:

• Sao lưu Full Database hàng tuần vào 18:00 ngày T7
• Sao lưu Transaction Log hàng ngày vào 18:00 các ngày CN, T2, T3, T4, T5, T6

Một sự cố xảy ra với database Accounting này lúc 15:00 ngày T4. Với các bản sao lưu Full và Transaction Log đang có, bạn có thể phục hồi database trở về thời điểm 18:00 của ngày T3. Tuần tự phục hồi như sau: Full T7 > Log CN > Log T2 > Log T3.

Có thể phục hồi database trở về thời điểm 18:00 của ngày T3 đã là điều rất tốt. Tuy nhiên, bạn vẫn mất lượng dữ liệu phát sinh từ 18:00 của ngày T3 (thời điểm sao lưu Transaction Log gần nhất) cho đến 15:00 của ngày T4 (thời điểm sự cố xảy ra). Rõ ràng sẽ tốt hơn nếu bạn có thể phục hồi database trở về thời điểm 14:59 của ngày T4 (ngay trước khi sự cố xảy ra).

Nội dung bên dưới sẽ giúp bạn hiểu rõ làm sao để đạt được khả năng phục hồi như vậy với Tail-Log Backup.

Tail-Log là gì?

Tail-Log là phần Transaction Log phát sinh kể từ lần sao lưu Transaction Log gần nhất đến thời điểm hiện tại. Tức là phần Transaction Log đang có Log file và chưa được sao lưu. Điều này cũng có nghĩa mỗi lần bạn sao lưu Transaction Log chính là sao lưu Tail-Log.

Có nhiều tình huống lỗi xảy ra với Data file nhưng Log file vẫn còn sử dụng được, VD:

• Lỗi logic do thao tác nhầm của DBA
• Ổ đĩa chứa Data file bị hỏng nhưng Log file lưu ở ổ đĩa khác nên không ảnh hưởng

Với những tình huống này, trước khi tiến hành phục hồi database, bạn sao lưu Transaction Log đang có trong Log file (chính là sao lưu Tail-Log). Sau đó sử dụng bản sao lưu này cùng các bản sao lưu Full Database và Transaction Log trước đó để phục hồi database. Với bản sao lưu Tail-Log này, bạn có thể phục hồi database trở về thời điểm hiện tại hoặc trở về bất kỳ thời điểm xác định nào trước đó (Point-in-Time Recovery).

Bên dưới mô tả 2 tình huống sao lưu Tail-Log khi SQL Server hoạt động bình thường và khi SQL Server bị lỗi khiến bạn không thể truy cập.

Tình huống 1: Sao lưu Tail-Log khi SQL Server hoạt động bình thường

Nếu sự cố chỉ xảy ra với Data file còn SQL Server vẫn hoạt động bình thường, việc tiến hành sao lưu Tail-Log là tương đối đơn giản. Bạn chỉ cần sử dụng lệnh BACKUP LOG và thêm tùy chọn NO_TRUNCATE để tiến hành sao lưu phần Transaction Log này.

Tình huống 2: Sao lưu Tail-Log khi SQL Server bị lỗi

Nếu sự cố nghiêm trọng khiến không chỉ mất Data file mà SQL Server cũng không thể hoạt động, bạn vẫn có thể sao lưu Tail-Log bằng cách dùng database tạm ở một SQL Server khác như sau:

• Tạo database tạm ở một SQL Server khác (nên tạo database cùng tên với database cần phục hồi)
• Xóa tất cả Data file và Log file của database đó (tất nhiên bạn cần tiến hành offline database hoặc tắt SQL Server)
• Sao chép Log file chứa Tail-Log muốn sao lưu vào thư mục chứa database
• Tiến hành sao lưu bằng lệnh BACKUP LOG với tùy chọn NO_TRUNCATE tương tự tình huống 1

Lưu ý quan trọng về Data file và Log file

Sao lưu Tail-Log mang lại khả năng phục hồi cực kỳ ý nghĩa cho database. Nhưng hẳn nhiên, bạn không thể tiến hành bước này nếu Log file không thể sử dụng. Do đó, một lưu ý quan trọng là bạn nên lưu trữ Data file (.MDF) và Log file (.LDF) của database trên các đĩa cứng/ổ đĩa khác nhau để giảm thiểu khả năng mất cả hai khi sự cố xảy ra.

Khi mất cả Data file và Log file, hẳn nhiên bạn chỉ có thể phục hồi database trở về thời điểm có bản sao lưu Transaction Log gần nhất.

The post Tail-Log Backup – Thao tác quan trọng trước khi phục hồi SQL Server appeared first on zBackup.vn | Sao lưu mô hình Hybrid Backup.

• Server bị hư ổ cứng
• Bạn thực hiện DELETE nhầm với database SQL Server
• Nhân viên lỡ tay xóa nhầm một sheet của Excel
• Lỗi phần mềm khiến dữ liệu bị lỗi
• Kẻ xấu phá hoại dữ liệu
• Cháy nổ nghiêm trọng

Vì thế, mọi hệ thống máy chủ hay ứng dụng khi được triển khai cần kèm theo một phương án sao lưu hữu hiệu. Lúc này đây, có thể bạn không thấy giá trị của việc này. Nhưng lúc sự cố xảy ra, nó chính là chiếc phao cứu sinh cho dữ liệu công ty bạn, và cho công việc của chính bạn.

7 kinh nghiệm bên dưới có thể giúp bạn xây dựng một chiến lược sao lưu hiệu quả hơn cho công ty mình.

1. Sao lưu đầy đủ những dữ liệu cần bảo vệ

Sẽ rất tệ khi bạn hì hục sao lưu nhưng những dữ liệu đó vẫn chưa đầy đủ những gì công ty bạn cần bảo vệ. Có khả năng nào như vậy không? Hoàn toàn có. Chẳng hạn: Công ty bạn có phần mềm kế toán chạy trên server. Nhưng đa phần hoạt động của công ty được vận hành bởi nhân viên sử dụng laptop/desktop. Những dữ liệu quan trọng nhất ảnh hưởng đến hoạt động của công ty là các file nằm trong các laptop/desktop này: file nghiên cứu, thiết kế, kho hàng, nguyên vật liệu, sản xuất, email,… Nếu chỉ tập trung sự chú ý vào dữ liệu kế toán trong server mà không có phương án sao lưu dữ liệu trong laptop/desktop của nhân viên, rõ ràng bạn đang thiếu sót.

2. Thông số Recovery Point Objective (RPO)

RPO là thông số tương đối khó hiểu, nó biểu thị lượng dữ liệu mà công ty bạn có thể chấp nhận mất mát khi sự cố xảy ra (tính bằng đơn vị thời gian, VD: lượng dữ liệu tương ứng 2 giờ làm việc, lượng dữ liệu tương ứng 1 ngày làm việc). Với những dữ liệu quan trọng ảnh hưởng lớn đến khả năng hoạt động liên tục của công ty, giá trị RPO càng nhỏ càng tốt. Tuy nhiên, điều này đòi hỏi bạn phải có một giải pháp sao lưu phù hợp.

Do đó, bạn cần đánh giá kỹ càng yêu cầu phục hồi của từng loại dữ liệu. Điều quan trọng là làm việc chặt chẽ với lãnh đạo công ty và lãnh đạo từng phòng ban liên quan. Để từ đó có thể xác định được giá trị RPO phù hợp và xây dựng giải pháp sao lưu tương ứng.

3. Sao lưu onsite hay offsite

Trong sao lưu, offsite luôn tốt hơn onsite. Nhưng offsite cũng đồng nghĩa bạn phải có phương án cho việc lưu trữ cách xa. Đó có thể là giải pháp đồng bộ dữ liệu đến một hệ thống ở chi nhánh qua đường truyền WAN, hoặc sao lưu vào thiết bị Tape/External HDD rồi mang đi lưu trữ cách xa. Bên cạnh đó, Cloud Backup cũng là lựa chọn đáng cân nhắc cho một giải pháp offsite an toàn và thuận tiện.

4. Sao lưu chi nhánh ở xa

Khi hoạt động công ty càng mở rộng, dữ liệu tại các văn phòng, nhà máy, chi nhánh cách xa cũng là điều bạn cần quan tâm bảo vệ trong vai trò của người IT. Thông thường, những địa điểm này không có nhân viên phụ trách IT và cũng quá xa để bạn có thể sao lưu trực tiếp bằng Tape hay External HDD. Do đó, giải pháp sao lưu qua đường truyền hoặc sử dụng Cloud Backup của nhà cung cấp dịch vụ là những phương án tốt cho tình huống này.

5. Chính sách và quy định sao lưu

Sao lưu dữ liệu không bao giờ là công tác chỉ làm một lần. Ngược lại, đó là công việc bạn phải thực hiện thường xuyên, đều đặn. Ở rất nhiều doanh nghiệp, có một thực tế là bản sao lưu gần nhất cách đây đã hơn một tháng, thậm chí một quý. Vậy làm cách nào bạn phục hồi được những dữ liệu mới phát sinh trong tháng vừa rồi khi sự cố xảy ra (trong khi đây là những dữ liệu quan trọng và cần thiết nhất)? Do đó, bạn cần phải có quy định và phân công rõ ràng để đảm bảo công tác sao lưu luôn được tiến hành đều đặn.

6. Xây dựng DR Plan

Làm cách nào phục hồi toàn bộ hệ thống ERP trong vòng 2 giờ? Nếu không có quy trình thực hiện rõ ràng từ trước, khả năng cao là bạn sẽ bối rối trong tình huống này. Bạn biết rất rõ khôi phục một hệ thống ERP không chỉ là việc phục hồi các bản sao lưu từ Tape, External HDD hay Cloud Backup. Mà bạn còn phải tiến hành rất nhiều bước để có thể khôi phục dữ liệu vào ứng dụng và cấu hình để hệ thống trở lại hoạt động như bình thường.

Giải pháp cho câu chuyện trên là bạn cần xây dựng một tài liệu DR Plan cho từng loại dữ liệu, tương ứng từng tình huống sự cố có thể xảy ra. Tài liệu cần xác định chi tiết từng bước thực hiện và phân công nhân sự rõ ràng. Chỉ như vậy, bạn mới có thể phản ứng một cách nhanh chóng và chính xác khi sự cố xảy ra một cách bất ngờ.

7. Tiến hành testing định kỳ

Khi sự cố xảy ra, bạn gắn Tape vào server và phát hiện không có dữ liệu sao lưu nào trong đó cả. Một câu chuyện kinh điển nhưng thực tế rất hay xảy ra. Bạn chỉ có thể ngăn ngừa tình huống này nếu thường xuyên testing công tác phục hồi. Những thay đổi trong quá trình testing cần được cập nhật vào tài liệu DR Plan. Điều quan trọng, công tác này cần được duy trì định kỳ hàng quý (hoặc lâu nhất là hàng năm).

zBackup | Dịch vụ sao lưu dữ liệu mô hình Hybrid Backup

Mang đến cho doanh nghiệp bạn một giải pháp sao lưu toàn diện, bảo mật và hiệu năng:

• Sao lưu Local vào External HDD / NAS Device
• Sao lưu Offsite về hệ thống zBackup
• Sao lưu vào Google Drive, Dropbox, Azure, AWS,…
• Hỗ trợ File, AD, SQL Server, Exchange Server
• Hỗ trợ Oracle, MySQL, VMware, Hyper-V
• Sao lưu tự động theo lịch và thời gian thực
• Mã hóa 256-bit AES & SSL
• DR Ready giúp sẵn sàng thảm họa

Xem mô hình Hybrid Backup ››

The post 7 kinh nghiệm cho một chiến lược sao lưu thành công appeared first on zBackup.vn | Sao lưu mô hình Hybrid Backup.

Các sự cố mất mát, hư hỏng dữ liệu luôn là điều đáng sợ với bất kỳ người quản lý IT nào. Càng đáng lo lắng hơn khi bạn biết rằng những sự cố này trước sau gì cũng xảy ra, vấn đề chỉ là lúc nào và mức độ nghiêm trọng như thế nào mà thôi. Điều tốt nhất người IT có thể làm là chuẩn bị và chuẩn bị một cách tốt nhất cho tình huống nó xảy ra.

Hẳn nhiên, việc triển khai một giải pháp dự phòng thảm họa (DR) hoàn chỉnh không phải là vấn đề đơn giản. Đặc biệt với các DN không có nhiều nguồn lực tài chính và nhân sự cho công tác IT. Nếu chưa biết bắt đầu từ đâu, 3 bước nền tảng bên dưới làm tham khảo quan trọng giúp bạn chuẩn bị cho tình huống DR.

1. Xác định RPO/RTO

Khi triển khai bất kỳ giải pháp nào, điều căn bản nhất để bắt đầu là xác định rõ mục tiêu muốn đạt được. Với DR, mục tiêu này chính là 2 giá trị: RPO và RTO. Đây là 2 giá trị bạn cần định lượng rõ và có sự thống nhất với lãnh đạo công ty. Bởi 2 giá trị này sẽ quyết định giải pháp và cơ chế bạn tiến hành sao lưu dữ liệu.

RPO – Recovery Point Objective

RPO là lượng dữ liệu mà công ty bạn chấp nhận mất mát khi sự cố xảy ra. Có thể bạn thắc mắc: Đã là DR thì sao lại có chuyện mất mát ở đây? Thực tế, chỉ trừ phi bạn triển khai giải pháp đồng bộ thời gian thực (Real-time Sync) thì mới không có mất mát dữ liệu khi sự cố xảy ra với hệ thống chính; còn ngoài ra, cho dù bạn sao lưu tốt thế nào thì khi phục hồi vẫn mất một lượng dữ liệu (so với khi không có sự cố). Trong ý nghĩa của RPO, lượng dữ liệu bị mất mát này có thể tính bằng đơn vị giờ làm việc, ngày làm việc,…

RPO là giá trị quan trọng bởi nó ảnh hưởng đến tần suất sao lưu dữ liệu. Và với những dữ liệu có yêu cầu RPO cao thì tần suất sao lưu này lại ảnh hưởng đến giải pháp, phần mềm sao lưu bạn chọn triển khai. Điều gì sẽ xảy ra nếu lãnh đạo công ty chỉ chấp nhận mất lượng dữ liệu 2 giờ nhưng bản sao lưu gần nhất bạn có thể phục hồi cách đó đã 1 tuần.

RTO – Recovery Time Objective

RTO xác định khoảng thời gian bạn tiến hành phục hồi để hệ thống có thể hoạt động trở lại, tức là khoảng thời gian công ty bạn chấp nhận ngưng trệ. Nếu thời gian này quá lâu, hoạt động công ty bạn chắc chắn gặp nhiều ảnh hưởng. VD: Bạn cần 2 ngày để phục hồi hệ thống mail Exchange Server, cũng đồng nghĩa trong 2 ngày đó nhân viên công ty bạn không thể liên lạc bằng email với khách hàng, đối tác. Hoặc phải sử dụng phương thức liên lạc khác.

2. Sao lưu offsite

Hẳn nhiên những sự cố dữ liệu thường xảy ra nhất là virus, hư ổ cứng, nhân viên thao tác nhầm. Ở những tình huống này, bản sao lưu onsite vẫn có thể giúp bạn phục hồi. Thậm chí rất nhanh vì bản sao lưu là onsite, bạn có thể nhanh chóng tiến hành hơn là bản offsite.

Tuy nhiên, bạn không thể biết được sự cố nào sẽ xảy ra với dữ liệu. Đó có thể là cháy nổ, kẻ xấu phá hoại, trộm cắp,… Với những thảm họa này, nếu bản sao lưu được lưu onsite gần dữ liệu gốc, khả năng mất mát cả hai là không nhỏ. Do đó, việc lưu trữ bản sao lưu offsite cách xa dữ liệu gốc vẫn là điều tốt hơn. Và tốt nhất là có cả bản sao lưu offsite lẫn onsite.

Nếu sao lưu bằng Tape hay HDD, bạn cần vận chuyển thiết bị này đi lưu trữ cách xa. Nếu dùng những dịch vụ Cloud Backup như zBackup, quá trình sao lưu offsite là hoàn toàn tự động. Bạn không phải mất thời gian tiến hành thao tác này.

3. Testing, testing, testing

Sao lưu là một chuyện nhưng phục hồi lại là chuyện khác. Tình huống sao lưu thường xuyên nhưng không thể phục hồi không phải là chuyện hiếm. Mà nguyên nhân chính ở đây là người IT không thường xuyên kiểm tra (testing) dữ liệu để kịp thời phát hiện các sai sót trong quá trình sao lưu. Có rất nhiều lý do dẫn đến tình trạng này: Tape bị lỗi không đọc được, bản sao lưu bị sai, hoặc thậm chí hoàn toàn không có dữ liệu trong Tape/Disk. Còn phải kể đến tình huống người IT vì không testing thường xuyên nên không nắm bắt được cách thức tiến hành phục hồi, đặc biệt với các ứng dụng phức tạp như Active Directory, SQL Server, Exchange Server, Oracle,…

The post 3 bước giúp bạn sẵn sàng cho thảm họa dữ liệu ngay từ bây giờ appeared first on zBackup.vn | Sao lưu mô hình Hybrid Backup.

Thật ra, công tác sao lưu thường được tiến hành rất tốt khi hệ thống vừa mới setup xong, hoặc mới có tình huống mất dữ liệu xảy ra (hoặc người IT mới nghe được câu chuyện mất dữ liệu tại một doanh nghiệp nào đó). Nhưng dần dần, mọi chuyện lại đâu vào đấy. Người IT lại bận rộn với các công việc triển khai ứng dụng mới, nâng cấp hệ thống, hỗ trợ end-user… Tính chủ quan lại dễ dàng trỗi dậy: “Không sao đâu. Để mai sao lưu cũng được.”

Để rồi dữ liệu không hề được sao lưu trong cả thời gian dài.

Hậu quả: Dữ liệu có thể phục hồi đã quá cũ

Khi không sao lưu trong thời gian dài, hoặc bạn không có bản sao lưu nào để phục hồi, hoặc bạn vẫn có nhưng dữ liệu đã quá cũ. Trong thời buổi mà hầu như tất cả hoạt động quản lý quan trọng của doanh nghiệp đều ứng dụng CNTT như hiện nay, việc mất lượng dữ liệu làm việc của một vài ngày hay một tuần đã là quá lớn. Nên với bản sao lưu cách đây đã 3 tháng, 6 tháng thì phục hồi cũng không còn nhiều ý nghĩa.

Một thống kê chỉ ra rằng hơn 80% nhu cầu phục hồi dữ liệu là với phiên bản mới nhất – tức phiên bản đang có ngay trước thời điểm sự cố xảy ra. Dễ dàng thấy rõ những dữ liệu mới chính là dữ liệu quan trọng nhất, bức thiết nhất ảnh hưởng đến hoạt động của công ty ở thời điểm hiện tại.

Cách khắc phục: Thiết lập lịch sao lưu tự động

Khẳng định tầm quan trọng của sao lưu nhưng không thể phủ nhận đây là công việc nhàm chán với hầu hết người IT. Bởi bạn phải tiến hành nó hàng ngày nhưng không chắc có ngày cần dùng đến (và bạn cũng không mong cần dùng đến). Vì thế, nếu chỉ dựa trên ý thức và sự cần mẫn của người IT thì công tác này sẽ chẳng mấy chốc đi vào quên lãng. Cho đến ngày thảm họa xảy ra.

Do đó, cách tối ưu nhất để khắc phục tình trạng này là sử dụng các phần mềm hỗ trợ để tiến hành sao lưu tự động giúp bạn không phải sao lưu thủ công hàng ngày. Ngày nay, hầu hết các phần mềm sao lưu (tính năng sao lưu có sẵn của Windows/Linux, các phần mềm sao lưu hư IBM TSM, Symantec Backup Exec, Acronis hay dịch vụ sao lưu Cloud Backup như zBackup, Carbonite) đều hỗ trợ tính năng đặt lịch sao lưu tự động. Bạn có thể dễ dàng sao lưu tự động hàng ngày, hàng tuần, hàng tháng hoặc sao lưu theo thời gian thực (Continuous Data Protection – CDP).

zBackup hỗ trợ sao lưu tự động theo lịch và thời gian thực (CDP)

Hẳn nhiên, có công cụ hỗ trợ sao lưu tự động không có nghĩa bạn có quyền quên hoàn toàn công tác này. Thay vào đó, bạn vẫn nên thường xuyên kiểm tra tình trạng sao lưu bằng cách xem kỹ các log báo cáo của phần mềm để kịp thời phát hiện bất kỳ sai sót nào. Đồng thời, định kỳ tiến hành phục hồi để kiểm tra dữ liệu và nắm bắt kỹ càng các bước thực hiện.

zBackup | Dịch vụ sao lưu dữ liệu theo mô hình Hybrid Backup

Mang đến cho doanh nghiệp bạn một giải pháp sao lưu toàn diện, bảo mật và hiệu năng:

• Sao lưu Local vào External HDD / NAS Device
• Sao lưu Offsite về hệ thống zBackup
• Sao lưu vào Google Drive, Dropbox, Azure, AWS,…
• Hỗ trợ File, AD, SQL Server, Exchange Server
• Hỗ trợ Oracle, MySQL, VMware, Hyper-V
• Sao lưu tự động theo lịch và thời gian thực
• Mã hóa 256-bit AES & SSL
• DR Ready giúp sẵn sàng thảm họa

Xem mô hình Hybrid Backup ››

The post Những sai lầm thường gặp trong DR: Không sao lưu thường xuyên appeared first on zBackup.vn | Sao lưu mô hình Hybrid Backup.

Cách duy nhất giúp quá trình Log truncation diễn ra để ngăn chặn tình trạng này là sao lưu Transaction Log thường xuyên. Bên cạnh đó, sao lưu Transaction Log còn mang giúp bạn tăng khả năng phục hồi khi lỗi xảy ra với Database. Vì chỉ có bản sao lưu Transaction Log mới giúp bạn phục hồi Point-in-Time. Và dữ liệu Transaction Log có dung lượng rất nhỏ nên bạn mới có thể sao lưu thường xuyên (điều khó thực hiện với sao lưu Full hay Differential).

1. Giúp khôi phục Database khi sự cố xảy ra

Sau khi khôi phục từ bản sao lưu Full (và Differential), bạn có thể sử dụng các bản sao lưu Transaction Log kế tiếp để khôi phục Database trở về thời điểm mong muốn. Vì Transaction Log lưu trữ tất cả thao tác cập nhật dữ liệu vào Database nên bạn có thể khôi phục Database trở về đúng thời điểm mong muốn (Point-in-Time Recovery).

Tham khảo 2 ví dụ bên dưới để thấy được vai trò quan trọng của bản sao lưu Transaction Log khi cần khôi phục Database.

Ví dụ 1: Database được sao lưu Full hàng ngày vào 21:00. Sự cố mất dữ liệu xảy ra vào 16:20. Nếu chỉ sao lưu Full, bạn chỉ có thể khôi phục Database trở về thời điểm 21:00 của hôm qua. Nghĩa là bị mất lượng dữ liệu phát sinh từ 21:00 hôm qua đến 16:20 hôm nay (tương ứng 19 giờ 20 phút). Ngược lại, nếu bạn sao lưu Transaction Log cứ 30 phút/lần (vào các thời điểm 21:30, 22:00,… 15:00, 15:30, 16:00), bạn có thể khôi phục Database trở về thời điểm gần nhất là 16:00. Nhờ đó, bạn chỉ mất lượng dữ liệu chỉ tương ứng 20 phút làm việc (phát sinh từ 16:00 đến 16:20). Rõ ràng nhỏ hơn rất nhiều so với lượng dữ liệu phát sinh trong 17 giờ 20 phút ở tình huống đầu.

Ví dụ 2: Database đang hoạt động bình thường, một Developer thực thiện thao tác UPDATE sai với hàng loạt dữ liệu lúc 10:42. Lỗi này không được phát hiện cho đến ngày hôm sau. Trong tình huống này, bạn cần khôi phục Database về thời điểm ngay trước khi thao tác UPDATE đó xảy ra. Nếu chỉ có bản sao lưu Full, bạn không thể thực hiện điều này (trường hợp may mắn nhất là bản sao lưu Full được tiến hành ngay trước khi thao tác UPDATE; nhưng đây chỉ là….may mắn). Ngược lại, nếu có bản sao lưu Transaction Log, bạn dễ dàng khôi phục Database trở về thời điểm ngay trước 10:42 bằng lệnh RESTORE LOG với tùy chọn STOPAT.

Vì Transaction Log có kích thước rất nhỏ (so với Database) nên bạn dễ dàng sao lưu thường xuyên mà không gây ảnh hưởng đến hiệu năng SQL Server cũng như dung lượng lưu trữ và đường truyền. Nếu sao lưu Full database (hoặc thậm chí Differential database), chắc chắn bạn khó có thể sao lưu với mật độ 30 phút/lần hoặc 1 tiếng/lần.

2. Giúp kích thước Log file không tăng lên

Với Database có Recovery model là FULL hoặc BULK-LOGGED, các Inactive log sẽ không được đánh dấu có thể tái sử dụng (reusable) cho dù Checkpoint xảy ra và dữ liệu được ghi từ vùng cache trên bộ nhớ xuống đĩa cứng. Quá trình này chỉ xảy ra khi bạn tiến hành sao lưu Transaction Log. Lúc đó, các Inactive log được đánh dấu là có thể tái sử dụng. Do đó, các Log record mới phát sinh có thể được ghi đè vào vùng lưu trữ này mà Log file không phải tăng thêm kích thước.

The post SQL Server: 2 lý do bạn cần sao lưu Transaction Log appeared first on zBackup.vn | Sao lưu mô hình Hybrid Backup.

Với Tape Backup (hoặc HDD Backup), bạn sao lưu SQL Server bao lâu một lần? Đa phần câu trả lời sẽ là: Tối đa 1 lần/ngày. Không ít trường hợp là cả tuần hoặc cả tháng mới sao lưu một lần. Và hầu hết là sao lưu Full Database.

Vậy điều này ảnh hưởng đến khả năng bảo vệ SQL Server thế nào? Cùng xem phân tích sau:

Giả sử bạn sao lưu Full Database vào 18:00 hàng ngày. Vào đúng 15:20 hôm nay, SQL Server bị sự cố gây mất tất cả database. Lúc này, bạn có thể khôi phục các database trở lại thời điểm có bản sao lưu gần nhất là 18:00 hôm qua. Đồng nghĩa một lượng dữ liệu tương đương 21 giờ 20 phút làm việc (từ 18:00 hôm qua đến 15:20 hôm nay) sẽ bị mất. Các dữ liệu này cần được nhập lại vào SQL Server hoặc chấp nhận mất mát.

Tình huống này rõ ràng gây ảnh hưởng không nhỏ đến hoạt động của công ty. Đặc biệt khi đây là những dữ liệu mới phát sinh nên ảnh hưởng rất lớn đến hoạt động của công ty. Ảnh hưởng sẽ càng nghiêm trọng nếu các dữ liệu này phát sinh từ nguồn bên ngoài công ty (VD: website thương mại điện tử) nên không biết làm cách nào để nhập lại.

Trên lý thuyết, tình huống xấu nhất có thể xảy ra là SQL Server bị sự cố lúc 17:59 phút. Nghĩa là công ty bạn sẽ mất lượng dữ liệu tương đương 24 giờ làm việc. Tức là RPO (Recovery Point Objective) = 24 giờ.

Sao lưu bằng zBackup

Khi sao lưu SQL Server bằng zBackup, bạn có thể sao lưu theo chính sách sau:

• Sao lưu Full Database: Ngay sau giờ làm việc (VD: 18:00 hàng ngày)
• Sao lưu Differential Database: Vào giờ nghỉ trưa (VD: 12:00 hàng ngày)
• Sao lưu Transaction Log: Cứ 1 giờ/lần

zBackup hỗ trợ cả 3 cơ chế sao lưu Full, Differential và Transaction Log nên bạn dễ dàng tạo một Backup Set và đặt lịch sao lưu tự động theo chính sách trên.

zBackup hỗ trợ sao lưu Full, Differential, Transaction Log của SQL Server

Với công nghệ In-File Delta và tính năng nén dữ liệu, zBackup giúp giảm thiểu lượng dữ liệu sao lưu xuống rất nhiều (với SQL Server thì tỉ lệ nén đạt đến 75-95%). Do đó, ngoại trừ lần sao lưu đầu tiên, tất cả các lần sao lưu sau đó đều có lượng dữ liệu rất ít (đặc biệt với Transaction Log, lượng dữ liệu này mỗi lần sao lưu chỉ từ vài chục KB đến vài MB). Do đó, việc sao lưu với tần suất trên dễ dàng hoàn tất.

SQL Server được nén rất tốt khi sao lưu

Khôi phục với RPO = 1 giờ

Khi sao lưu với tần suất như trên, dù sự cố xảy ra với SQL Server ở bất kỳ thời điểm nào, bạn đều có thể khôi phục các database trở lại thời điểm trong vòng 1 giờ trở lại.

Cùng xem phân tích bên dưới:

Giả sử sự cố xảy ra vào 16:30. Lúc này, bạn có thể khôi phục database trở lại thời điểm 16:00 bằng cách tiến hành theo thứ tự như sau:

• Khôi phục bản sao lưu Full Database lúc 18:00 (đêm hôm qua)
• Khôi phục bản sao lưu Differential Database lúc 12:00
• Lần lượt khôi phục các bản sao lưu Transaction Log lúc 13:00, 14:00, 15:00, 16:00

Vì các database được khôi phục trở lại thời điểm 16:00 nên lượng dữ liệu bị mất chỉ tương đương với 30 phút làm việc (lượng dữ liệu mới phát sinh, thay đổi từ 16:00 đến 16:30). Tình huống mất dữ liệu nhiều nhất có thể xảy ra với chính sách sao lưu này là 1 giờ, tương ứng RPO = 1 giờ.

Kết luận

Từ phân tích với 2 ví dụ trên, bạn dễ dàng thấy rằng zBackup có thể giúp bạn nâng cao tần suất sao lưu dữ liệu lên gấp 24 lần so với Tape Backup. Trong khi hầu như không gây ảnh hưởng đến hiệu năng server, không tốn nhiều dung lượng lưu trữ; và quá trình sao lưu hoàn toàn tự động. Đặc biệt, với bản chất tự nhiên của một dịch vụ Cloud Backup, dữ liệu được lưu trữ offsite cách xa hoàn toàn tự động mỗi lần sao lưu. Nên dù xảy ra các sự cố nghiêm trọng như cháy nổ, phá hoại thì bạn vẫn đảm bảo khả năng phục hồi với RPO = 1 giờ.

Trong khi đó với Tape Backup, dù bạn cố gắng sao lưu 1 lần/ngày nhưng không lưu trữ offsite cách xa theo đúng tần suất này thì với các thảm họa vật lý như trên, bạn cũng không đảm bảo RPO = 24 giờ.

# Free ebook: 8 lưu ý quan trọng khi sao lưu & phục hồi SQL Server

Kinh nghiệm giúp bảo vệ an toàn database SQL Server

Ebook chia sẻ những lưu ý quan trọng trong quá trình sao lưu và phục hồi SQL Server. Áp dụng các lưu ý có thể giúp bạn nâng cao đáng kể tính an toàn và khả năng phục hồi khi sự cố xảy ra với database SQL Server.

Download Now ››

The post SQL Server: Vì sao zBackup có thể giúp bạn tăng khả năng bảo vệ dữ liệu lên 24 lần so với Tape Backup? appeared first on zBackup.vn | Sao lưu mô hình Hybrid Backup.

Bạn sử dụng bao nhiêu mật khẩu cho các tài khoản của mình? Chỉ một! Nếu đúng vậy, bạn đang mắc một lỗi căn bản trong nguyên tắc đặt mật khẩu cho tài khoản đăng nhập (đăng nhập HĐH, đăng nhập phần mềm, đăng nhập các tài khoản mạng xã hội,…). Rất khó để bạn có thể đặt mỗi mật khẩu cho một tài khoản. Nhưng việc đặt tất cả tài khoản chung một mật khẩu là điều tối kỵ.

Tham khảo 6 kinh nghiệm sau có thể giúp bạn có được một mật khẩu đảm bảo tính bảo mật cao hơn.

• KHÔNG NÊN sử dụng những từ/cụm từ thông dụng, dễ đoán như 123, 123456, 1010
• NÊN sử dụng các ký tự không phải dạng anphabet như ?%!$.
• KHÔNG NÊN sử dụng các thông tin liên quan đến cá nhân bạn để đặt mật khẩu, chẳng hạn tên, ngày tháng năm sinh của bạn, hay tên con vật nuôi yêu quý của bạn. Những mật khẩu dàng này rất dễ bị đoán ra.
• NÊN đặt mật khẩu càng dài càng tốt (tất nhiên trong giới hạn số ký tự cho phép nếu ứng dụng có quy định yếu tố này). Mật khẩu càng dài chắc chắn sẽ càng khó đoán với con người. Với các phần mềm dò tìm mật khẩu thì mật khẩu càng dài chắc chắn càng mất nhiều thời gian hơn.
• KHÔNG NÊN sử dụng chung một mật khẩu cho nhiều tài khoản khác nhau. Bởi khi đó, nếu sơ suất xảy ra gây rò rỉ mật khẩu của tài khoản này dễ dẫn đến gây hại cho các tài khoản khác. Do đó, bạn nên sử dụng nhiều mật khẩu cho nhiều tài khoản khác nhau.
• NÊN sử dụng các công cụ phần mềm Password Management. Những công cụ này sẽ giúp bạn tạo mật khẩu có độ an toàn cao; đồng thời giúp bạn thuận tiện quản lý và sử dụng. Những công cụ được đánh giá cao là KeePass, LastPass, 1Password.

The post 6 kinh nghiệm đặt mật khẩu an toàn appeared first on zBackup.vn | Sao lưu mô hình Hybrid Backup.

Cách duy nhất để bạn chắc chắn về khả năng phục hồi là thường xuyên kiểm tra dữ liệu sao lưu. Lần gần đây nhất bạn kiểm tra là khi nào? Nếu đã quá lâu, hãy tiến hành ngay đi. Đừng để quá muộn!

Những nguyên nhân khiến bạn không thể phục hồi dữ liệu?

Thực tế, có rất nhiều nguyên nhân khiến bạn không thể phục hồi đúng dữ liệu cần. Bên dưới là những tình huống hay xảy ra nhất:

1. Thiết bị lưu trữ dữ liệu sao lưu bị hỏng

Bạn sao lưu bằng Tape/HDD và lưu trữ offsite ở chi nhánh khác hoặc mang về nhà cất? Vậy bạn có chắc đến khi cần phục hồi, Tape Cartridge vẫn hoạt động bình thường và dữ liệu vẫn đọc được. Thật sự không có gì chắc chắn cả. Đặc biệt với dạng thiết bị lưu trữ chuyên dụng như Tape. Có thể Tape Cartridge bị hư hỏng gây mất dữ liệu. Có thể Tape Drive có vấn để nên chỉ có thể ghi (write) chứ không thể đọc (read).

Có rất nhiều trường hợp công nghệ Tape mà công ty sử dụng đã quá cũ, Tape Drive bị hỏng không thể sửa chữa hay thay thế. Lúc đó, các bản sao lưu trong Tape Cartridge là hoàn toàn vô nghĩa.

2. Dữ liệu sao lưu không đúng (hoặc không có)

Khá lâu trước đây, bạn đã thiết lập việc sao lưu chuẩn mực và không có gì lo lắng. Nhưng một ngày nào đó, dữ liệu bị di dời sang thư mục khác mà bạn quên điều chỉnh thiết lập trong phần mềm. Phần mềm vẫn chạy hàng ngày mà bạn không mảy may để ý. Đến ngày gặp sự cố mới phát hiện dữ liệu cần sao lưu hoàn toàn không được sao lưu. Tất nhiên lúc này bạn không có gì để phục hồi.

Hoặc một câu chuyện khác là vì sao lưu thủ công bằng HDD/Tape nên bạn lưu trữ rất ít phiên bản. Một thư mục dữ liệu nào đó bị lỗi bên trong nhưng hoàn toàn không hay biết và vẫn được sao lưu hàng ngày. Cho đến ngày phát hiện ra thì tất cả phiên bản có thể phục hồi đều là phiên bản lỗi. Phiên bản trước khi lỗi đã không còn vì bi ghi đè bởi các phiên bản lỗi.

3. Quên khóa mã hóa

Hầu hết các phần mềm sao lưu đều hỗ trợ mã hóa bằng hình thức khóa riêng (Private Key) nên Khóa mã hóa là do người dùng tự nhập vào. Với cơ chế này, Khóa là duy nhất và không được lưu trữ ở bất kỳ nơi nào khác. Nên hiển nhiên, bạn không thể nào lấy lại được dữ liệu nếu quên Khóa.

Bạn sẽ không quên ngay lập tức. Nhưng nếu thời gian là khá lâu và bạn không kiểm tra. Có thể bạn sẽ quên. Đặc biệt ở tình huống chuyển công tác quản lý sao lưu từ người này sang người khác mà không kiểm tra kỹ càng.

4. Không biết cách phục hồi

Nghe khá kỳ cục. Nhưng đây là tình huống không hiếm chút nào. Nhất là khi phục hồi với Tape và bản sao lưu nằm trên nhiều Tape Cartridge khác nhau. Bởi có thể bạn sao lưu hàng ngày nhưng chưa bao giờ tiến hành phục hồi từ Tape.

Nhưng câu chuyện thường xảy ra nhất với tình huống này là khôi phục các ứng dụng như SQL Server, Exchange Server, Oracle,… Khác với dữ liệu dạng file, với dữ liệu của các ứng dụng này, bạn không chỉ phục hồi dữ liệu từ Tape, HDD, Cloud mà còn phải khôi phục dữ liệu vào ứng dụng (thường sử dụng chức năng Restore của ứng dụng). Thao tác này đòi hỏi bạn phải nắm vững kiến thức khôi phục dữ liệu các ứng dụng. Nếu không, rất dễ sai sót và thậm chí không biết làm sao để phục hồi. Trong khi đó, thời gian đưa hệ thống trở lại hoạt động (Recovery Time Objective – RTO) là yếu tố cực kỳ quan trọng khi thảm họa xảy ra. Bất cứ chậm trễ nào đều có thể gây ra thiệt hại không lường trước được.

Hãy kiểm tra dữ liệu thường xuyên!

Khả năng bạn rơi vào những tình huống trên là không nhỏ. Nên cách duy nhất là tiến hành kiểm tra thường xuyên. Nếu là dữ liệu dạng File, hãy định kỳ phục hồi ngẫu nhiên một vài file. Nếu là những dữ liệu cấu trúc như SQL Server, Exchange Server,… hãy tìm hiểu kỹ cách thức khôi phục và định kỳ tiến hành khôi phục một số database, mail quan trọng. Hoặc sử dụng các chức năng hỗ trợ của các ứng dụng này cho việc kiểm tra bản sao lưu.

zBackup | Dịch vụ sao lưu dữ liệu mô hình Hybrid Backup

Mang đến cho doanh nghiệp bạn một giải pháp sao lưu toàn diện, bảo mật và hiệu năng:

• Sao lưu Local vào External HDD / NAS Device
• Sao lưu Offsite về hệ thống zBackup
• Sao lưu vào Google Drive, Dropbox, Azure, AWS,…
• Hỗ trợ File, AD, SQL Server, Exchange Server
• Hỗ trợ Oracle, MySQL, VMware, Hyper-V
• Sao lưu tự động theo lịch và thời gian thực
• Mã hóa 256-bit AES & SSL
• DR Ready giúp sẵn sàng thảm họa

Xem mô hình Hybrid Backup ››

The post Lần gần đây nhất bạn kiểm tra dữ liệu sao lưu là khi nào? appeared first on zBackup.vn | Sao lưu mô hình Hybrid Backup.