# Seafile FSCK 在服務器端，Seafile 通過一種內部格式將文件存儲在資料庫中。Seafile 對于文件和目錄有其獨有的表現方式（類似于Git）。 默認安裝下，這些內部對象，會被直接存儲在服務器的文件系統中（例如 Ext4，NTFS）。由于大多數文件系統，不能在服務器非正常關閉或系統崩潰后，保證文件內容的完整性。所以，如果當系統崩潰時，正在有新的內部對象被寫入，那么當系統重啟時，這些文件就會被損壞，相應的資料庫也無法使用。 注意: 如果你把 seafile-data 目錄存儲在有后備電源的 NAS（例如 EMC 或 NetApp）系統中，或者使用 S3 作為專業版的服務器，內部對象不會被損壞。 從 2.0 版開始，Seafile 服務器引入了 `seafile-fsck` 工具來幫助你恢復這些毀壞的對象（類似于git-fsck工具）。這個工具將會進行如下兩項工作： 1. 檢查 Seafile 內部對象的完整性，并且刪除毀壞的對象。 1. 恢復所有受影響的資料庫到最近一致，可用的狀態。 4.1 及之后的版本，我們提供一個 seaf-fsck.sh 腳本來運行 seafile-fsck 工具。 執行流程如下所示： ~~~ cd seafile-server-latest ./seaf-fsck.sh [--repair|-r] [--enable-sync|-e] [repo_id_1 [repo_id_2 ...]] ~~~ seaf-fsck 有檢查資料庫完整性和修復損壞資料庫兩種運行模式。 ### 檢查資料庫完整性 執行 seaf-fsck.sh 不加任何參數將以**只讀**方式檢查所有資料庫的完整性。 ~~~ cd seafile-server-latest ./seaf-fsck.sh ~~~ 如果你想檢查指定資料庫的完整性，只需將要檢查的資料庫 ID 作為參數即可： ~~~ cd seafile-server-latest ./seaf-fsck.sh [library-id1] [library-id2] ... ~~~ 運行輸出如下: ~~~ [02/13/15 16:21:07] fsck.c(470): Running fsck for repo ca1a860d-e1c1-4a52-8123-0bf9def8697f. [02/13/15 16:21:07] fsck.c(413): Checking file system integrity of repo fsck(ca1a860d)... [02/13/15 16:21:07] fsck.c(35): Dir 9c09d937397b51e1283d68ee7590cd9ce01fe4c9 is missing. [02/13/15 16:21:07] fsck.c(200): Dir /bf/pk/(9c09d937) is curropted. [02/13/15 16:21:07] fsck.c(105): Block 36e3dd8757edeb97758b3b4d8530a4a8a045d3cb is corrupted. [02/13/15 16:21:07] fsck.c(178): File /bf/02.1.md(ef37e350) is curropted. [02/13/15 16:21:07] fsck.c(85): Block 650fb22495b0b199cff0f1e1ebf036e548fcb95a is missing. [02/13/15 16:21:07] fsck.c(178): File /01.2.md(4a73621f) is curropted. [02/13/15 16:21:07] fsck.c(514): Fsck finished for repo ca1a860d. ~~~ 被損壞的文件和目錄將顯示在輸出的結果中。 有時，你會看到如下的輸出結果： ~~~ [02/13/15 16:36:11] Commit 6259251e2b0dd9a8e99925ae6199cbf4c134ec10 is missing [02/13/15 16:36:11] fsck.c(476): Repo ca1a860d HEAD commit is corrupted, need to restore to an old version. [02/13/15 16:36:11] fsck.c(314): Scanning available commits... [02/13/15 16:36:11] fsck.c(376): Find available commit 1b26b13c(created at 2015-02-13 16:10:21) for repo ca1a860d. ~~~ 這意味著記錄在數據庫中的 "head commit" （當前資料庫狀態的標識）與數據目錄中的記錄不一致。這種情況下，fsck 會試著找出最近可用的一致狀態，并檢查其完整性。 建議: **如果你有很多資料庫要檢查，保存 fsck 的輸出到日志文件中將有助于后面的進一步分析。** ### 修復損壞的資料庫 fsck 修復損壞的資料庫有如下兩步流程: 1. 如果記錄在數據庫中的資料庫當前狀態無法在數據目錄中找出，fsck 將會在數據目錄中找到最近可用狀態。 1. 檢查第一步中可用狀態的完整性。如果文件或目錄損壞，fsck 將會將其置空并報告損壞的路徑，用戶便可根據損壞的路徑來進行恢復操作。 執行如下命令來修復所有資料庫： ~~~ cd seafile-server-latest ./seaf-fsck.sh --repair ~~~ 大多數情況下我們建議你首先以只讀方式檢查資料庫的完整性，找出損壞的資料庫后，執行如下命令來修復指定的資料庫： ~~~ cd seafile-server-latest ./seaf-fsck.sh --repair [library-id1] [library-id2] ... ~~~ 由于被損壞的文件或目錄在修復過后會被置空，在客戶端同步被修復的損壞資料庫將會導致數據丟失，即客戶端先前好的完整的文件或目錄拷貝將被空文件或空目錄替代。為了避免這種情況發生，服務器將會阻止客戶端同步被**修復**的損壞資料庫。系統管理員應該通知用戶來恢復損壞的文件或目錄，然后執行如下命令讓此資料庫可以再次同步： ~~~ cd seafile-server-latest ./seaf-fsck.sh --enable-sync [library-id1] [library-id2] ... ~~~