使用 Systemd 定時器可靠地執行 ownCloud 後台作業
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
在啟用了 Snapper 且根檔案系統為 Btrfs 的標準 SUSE Linux Enterprise Server (SLES) 系統上,最安全的復原方法是啟動失敗更新之前所建立的快照,在唯讀狀態下進行測試,然後執行復原指令sudo snapper rollback。這將從測試狀態建立一個新的可寫根分割區;它不會回滾每個磁碟、子磁碟區或應用程式資料庫。
目前的 SLES 15 SP7 管理指南仍然採用這種啟動和測試工作流程。在執行此操作之前,請確認機器符合 SUSE 支援的回溯佈局,並確定失敗的 Zypper 或 YaST 交易的預快照。
否。可引導系統回滾僅適用於預設 Snapperroot配置中的快照。 SUSE 文件支援預設的根子磁碟區配置,即單一根裝置上的 Btrfs 檔案系統以及已安裝的可用開機載入程式。回滾操作會更改子卷的內容/;其他子卷不會被更改。在典型的 SLES 佈局中,諸如/var`/ usr / local/bin`、` /srv/ usr/local/bin`、`/usr/ local/bin` 和 `/usr/local/bin` 之類的路徑通常位於快照之外。因此,即使系統軟體套件已回滾,資料庫或服務仍可能保留快照後寫入的資料。/opt/usr/local/home
在執行回滾作業之前,請務必備份或驗證重要的應用程式資料。此外,如果您變更了預設的 Btrfs 子磁碟區佈局或使用了多裝置根目錄,也請避免執行此操作:SLES 15 SP7 文件中記錄的可啟動回溯要求不涵蓋這些設定。請在繼續操作之前閱讀 SUSE 的Snapper 恢復要求。
使用 Snapper 設定根檔案系統,並比較交易的執行前/執行後快照對。在啟用了 Btrfs 根快照的典型 SLES 系統中,Zypper 和 YaST 會在套件操作前後建立快照。執行前快照表示該操作之前的根狀態;執行後快照表示該操作執行後的狀態,包括部分失敗的交易。
sudo snapper list-configs。尋找名為 . 的配置root。findmnt -no FSTYPE /。對於此可引導回滾過程,它應該會報告btrfs。然後運行sudo btrfs filesystem show /並確認根檔案系統報告Total devices 1。sudo snapper -c root list -t pre-post。將日期和描述與失敗的更新進行配對。在Pre #列中記錄編號,而不是配對的事務對Post #。PRE和替換POST為您機器上顯示的數字:sudo snapper -c root status PRE..POST
sudo snapper -c root diff PRE..POST
這些命令會列出已變更的路徑和檔案差異。快照編號、日期、軟體包說明和輸出因主機而異;請勿從螢幕截圖複製範例編號。如果沒有出現相關的快照對,請檢查 Snapper 是否已啟用,以及清理策略是否已刪除該快照。 Snapper 無法事後重新建立遺失的快照。

重新啟動並使用引導程式的快照條目。在 SLES 系統中,選擇「啟動」Start Bootloader from a read-only snapshot,然後選擇失敗事務發生前不久的快照。啟動選單會以日期和描述標記項目,描述可能包括zypp(zypper)YaST 操作。選擇您記錄的更新前快照;不要因為更新後快照的描述更容易識別就選擇它。
登入並測試故障的服務或應用程式。在此測試期間,快照的根檔案為唯讀,因此僅此一次啟動不會變更預設根目錄。如果快照錯誤或系統仍然發生故障,請重新啟動並嘗試另一個快照,或使用救援系統。請勿僅為了使選單選項永久生效而強制回滾。

僅在舊快照啟動並通過所有檢查後才執行回滾操作。從該只讀快照執行以下命令:
sudo snapper rollback
然後重新啟動並選擇正常的預設啟動項目:
sudo reboot
Snapper 會保留回滾前系統狀態的快照,並基於該快照建立新的讀寫根目錄。在文件中記錄的從快照啟動工作流程中,您無需將舊快照編號傳遞給此命令。最終結果是一個新的預設根目錄,而不是將只讀快照本身轉換為可寫入目錄。快照稍後可能會被清理規則刪除,因此在將舊的回滾快照用作長期存檔之前,請先複製所有必需的檔案。

啟動預設入口點,並檢查實際的恢復情況,而不僅僅是命令是否執行完畢。確認內核和軟體包狀態是否符合預期,查看故障服務的狀態和日誌,並執行一個簡單的應用程式層級檢查。然後檢查 Snapper 的新狀態:
sudo snapper -c root list
對於普通的軟體包更新,這通常足以確認機器從新的根目錄啟動。如果失敗的操作是服務包遷移,則應遵循 SUSE 的回溯後檢查步驟:刷新並檢查軟體倉庫,然後檢查註冊:
sudo zypper ref -fs
sudo zypper lr
sudo SUSEConnect --status
軟體倉庫應與您恢復到的服務包相匹配,並且已安裝的產品應已註冊。如果註冊未恢復,請依照 SUSE 的SLES 15 SP7 服務包回溯流程文件中的sudo SUSEConnect --rollback步驟進行修復。此註冊命令專門用於遷移恢復;請勿將其用於常規軟體包更新。

如果此主機使用transactional-update(例如,交易型 SLE Micro 系統),請遵循該產品的步驟,而不是套用傳統的 SLES 指令序列。該產品的文檔中提供了sudo transactional-update rollback SNAPSHOT_NUMBER從運行系統中選擇快照的方法,以及在當前根目錄損壞時使用單獨的啟動只讀快照工作流程。請參閱 SUSE 的交易更新回滾說明。
將按需作業運行替換為 systemd 定時器,該定時器每 15 分鐘執行一次 ownCloud 支援的 occ system:cron 命令。
透過 Apache、Nginx 或反向代理程式追蹤 WebDAV 請求,然後使用經過驗證的 PROPFIND 測試確認 ownCloud 同步功能正常。
透過設定其規範 URL 並從伺服器本身檢查 DNS、HTTPS 和反向代理路由,修復 Nextcloud 缺少出站位址警告的問題。
透過本機 Unix 套接字配置 APCu 和 Redis,以實現 Nextcloud 快取和檔案鎖定,並提供目前和舊版 Nextcloud 的步驟。
檢查 Nextcloud 的 cron 模式,修復其 systemd 服務和計時器,並驗證後台作業在啟動後以及每隔五分鐘運行一次。
啟用可靠的 Nextcloud 檔案鎖定,選擇適當的 Redis 或 Valkey 後端,並驗證警告是否清除,同時避免並發檔案變更的風險。
使用最新更新、HTTPS 和 HSTS、精確的反向代理信任以及針對公共伺服器的檢查,修復 Nextcloud 掃描中常見的錯誤。
為需要加密的儲存配置 Nextcloud SSE,保護加密金鑰,並在加密現有文件之前測量傳輸和 CPU 影響。
將 Nextcloud 的檔案搜尋連接到 Elasticsearch,索引文件內容,並選擇適合您的伺服器和安全需求的設定。
配置 Nextcloud 在規定的保留期後刪除已刪除的文件,可靠地安排後台作業,並避免執行清除所有使用者回收站的命令。