Centos 6 - 備份和恢復/恢復

我正在嘗試測試和記錄 Centos 6 的備份和恢復過程。這是我要做的，但有一些地方我需要澄清一下。’net 上的 CentOS 備份/恢復文件有點偶然。

一般備份和恢復計劃

• 每天使用您最喜歡的備份軟體備份您的系統。我不打算深入討論這個問題，但假設您有一個適當的備份系統，可以讓您備份一個系統並將其恢復到另一個系統。
• 煙霧和火焰吞沒了您的一台伺服器！在處理了眼前的危險之後，您會意識到一個重要的系統已受到不可挽回的損壞。您需要將其還原到不同的硬體。
• 檢查備份文件。查看故障系統/etc/redhat-release文件的備份。使用它來確定故障系統使用的 CentOS 版本（更新檔級別）？獲取此版本的安裝媒體。
• 使用安裝介質，對您的替換硬體進行最低限度的作業系統安裝，根據系統的最終用途對磁碟進行分區。
• 安裝最小系統後，暫時禁用 selinux，echo ‘0’> /selinux/enforce停止 iptables，service iptables stop然後安裝備份客戶端。
• 從備份中恢復，從恢復中排除以下文件：

/proc
/sys
/tmp
/dev
/var/lock <- 不要從恢復中排除 - 請參閱答案
/var/run <- 不要從恢復中排除 - 請參閱答案

/var/tmp
/etc/fstab
/etc/mdadm .conf
/etc/mtab

/etc/resolv.conf
/etc/networks
/etc/sysconfig/network*

/etc/sysconfig/kernel
/etc/hosts
/etc/modprobe*
/etc/networkmanager <- 確保 IP 不是t 已恢復 - 請參閱答案

/etc/udev
/lib/modules
/boot

• 還原完成後，重新啟動並註意錯誤
• 檢查網路配置是否正確。您可能需要使用system-config-network來更改您的網路設置。
• 某些應用程序（如 Apache 和 MySQL）在恢復後可能無法正確啟動。由於/var/run已從還原中排除，/var/run/httpd因此不會存在子文件夾，因此應用程序將無法正確創建 PID 文件。您需要恢復文件夾/var/run/httpd/，/var/run/mysqld/並賦予它們正確的權限。 只要您不從還原中排除 /var/run 和 /var/lock ，這應該不是問題 - 請參閱答案。
• 完成補救措施後，確保應用程序正確啟動。
• 如果您正在執行 MySQL 數據庫，它可能仍然可以，而無需從您可能已製作的任何平面文件備份中恢復它。您可以通過執行來檢查數據庫的狀態mysqlcheck -c -u root –p******** --all-databases。如果您看到任何錯誤，請執行mysqlcheck -c -u root –p******** --all-databases --auto-repair以修復它們。您應始終確保正確備份數據庫，如下面的答案所示。我個人使用mysqldump。
• 使用 . 將系統修補到最新級別yum update。
• 重新啟動以確保系統清晰且徹底地檢查 /var/log/messages 是否有任何錯誤後，測試系統的功能以確保其正常執行。在這種情況下，請使用system-config-network將 IP 地址更改為原始故障系統的 IP 地址。

問題/疑問

• 從還原中排除/var/run/*會導致在還原時不創建用於包含某些應用程序的 PID 的子文件夾。真的有必要/var/run/*從恢復中排除嗎？是一種更好的方法來簡單地不恢復 PID 文件嗎？
• 當系統恢復時，“故障系統”的IP地址也被恢復了。我不想要這個。我一定錯過了“從恢復中排除”列表中的一個文件。任何想法它在哪裡？
• 更新時，我收到很多消息，例如/sbin/ldconfig: /usr/lib64/libblah.so is not a symbolic link. 當我在更新某些服務後重新啟動系統時，無法正確啟動。我想知道這是否與備份系統恢復符號連結指向的文件而不是符號連結本身有關。如果我執行 ldconfig 並查看它抱怨的共享對象之一，則共享對像是實際文件而不是符號連結。還有人看到這個嗎？

1. 排除/var/run

正如您已經註意到的，/var/run在 CentOS 6 系統的完全還原期間排除會導致問題，因為它還排除了由已安裝軟體包創建的目錄。排除/var/lock也會導致類似的問題，因為一些包也會在那裡創建子目錄。

（在最近的 Linux 發行版上可能沒有此類問題，在systemd 此類發行版上/var/lock，/var/run（真的/run）可能會放置在用於在或tmpfs中自動創建子目錄。）/var/lock``/var/run

但是，實際上排除/var/run並且/var/lock不需要正確還原，因為/etc/rc.d/rc.sysinitCentOS 6 上的腳本包含以下命令：

find /var/lock /var/run ! -type d -exec rm -f {} \;

此命令將在系統引導期間刪除所有過時的鎖或 pid 文件（或任何其他非目錄文件，例如套接字和符號連結）。因此，您應該從恢復排除列表中刪除/var/lock和。/var/run

2.網路配置文件的位置

/etc/sysconfig/network*您在恢復備份時已經排除；這應該匹配/etc/sysconfig/network文件（全域網路配置）和/etc/sysconfig/network-scripts目錄（每個介面配置文件ifcfg-*）。然而，這些文件只被包含在軟體包中的老式網路配置腳本initscripts使用，而 CentOS 6 有另一個網路配置系統—— NetworkManager，其配置儲存在/etc/NetworkManager. 還原備份時也嘗試排除該目錄。

3. 符號連結被文件替換的問題

如果您看到恢復後符號連結被替換為普通文件，這意味著您的備份/恢復程序配置不正確，或者（如果沒有保存和恢復實際符號連結的選項）您使用的程序不合適完全用於 Linux 系統備份/恢復。只有當程序僅用於備份和恢復某些絕對不包含符號連結的特定數據時，您才能擺脫不支持符號連結的程序。請注意，您可能會在意想不到的地方找到符號連結——例如，在某些情況下，符號連結可能會在 MySQL 數據庫目錄中使用（將部分數據儲存在不同的設備上），因此依賴於“無符號連結”假設可能很危險。

4. MySQL備份

如果您的備份程序只是從正在執行的伺服器複製文件，那麼您的備份並不是真正的“崩潰一致性”，因為不同的文件（甚至同一文件的不同塊）在不同的時間被複製，因此您實際上不會獲得一致的快照備份中的數據庫。（這適用於任何類型的數據庫，而不僅僅是 MySQL。）

有幾種方法可以僅使用文件級備份來備份 MySQL 數據庫：

1. 用於mysqldump在啟動文件級備份之前創建 SQL 轉儲；備份轉儲文件而不是數據庫目錄。這是最便攜的備份格式，但轉儲和恢復都可能很慢。
2. 在開始備份之前停止 MySQL 伺服器，進行文件級備份，然後再次啟動 MySQL 伺服器。要恢復，只需恢復新伺服器上的所有文件，然後正常啟動伺服器即可。這種備份速度很快，但在備份過程中需要很長的停機時間。
3. 為了減少前一種方法所需的 MySQL 伺服器停機時間，您可以在停止伺服器後創建文件系統快照，然後重新啟動 MySQL 伺服器，然後掛載快照，執行文件級備份並刪除快照。您需要將文件系統放在 LVM 卷上，卷組中有一些可用空間用於快照。
4. 為了進一步減少停機時間，您可以FLUSH TABLES WITH READ LOCK在拍攝快照之前使用，而不是停止伺服器，如此處所述；在這種情況下，快照將包含處於一致狀態的 MyISAM 表，以及處於崩潰一致狀態的 InnoDB 表（文件級恢復後需要 InnoDB 恢復）。

閱讀此文件以獲取有關 MySQL 備份的更多資訊。

引用自：https://serverfault.com/questions/514315