源鏈接 https://yq.aliyun.com/articles/69179?spm=5176.8217306.rtdmain.3.X8cYJF
Gitlab 也給出了自己的解決方案和未來針對備份的ToDo list1. 更改服務器終端的顏色來區分生產環境（紅色）、測試環境（黃色）。2. 定期檢查數據庫備份的目錄，查看備份的數據是否成功備份。3. 添加備份提醒，定期檢查S3 Bucket的大小，如果備份大小小于數據庫大小、備份頻率超過設定的時間，就發送警告。4. 調整 PostgreSQL 的配置，線上環境中 PGSQL 的連接數過大，導致備份失效，從8000降到2000，或者使用數據庫連接池。
庫級一致性，備份只能恢復到單一時間點，無法做到增量恢復，無法做到增量的備份。
另一方面還要注意，由于大版本不同的數據庫，往往catalog也可能不一樣，所以邏輯備份使用的備份客戶端pg_dump的版本，建議與數據庫的版本一致。否則是可能會有備份異?；蛘呤〉目赡?如果沒有注意到這一點，就有可能導致邏輯備份失敗哦)。
《PostgreSQL 最佳實踐 - 在線邏輯備份與恢復介紹》
最為常見的備份方式，可以在線進行，可以恢復到任意時間點（事務粒度）。
如果忽視了這一點，在使用pg_basebackup備份時，如果目標備份目錄已存在，同時目錄不為空，備份也會異常。
請參考pg_basebackup手冊，已經寫明(這么做也許是為了保證每次備份的穩定性，不會受到已有文件的干擾或打斷，作為備份工具設計者，鬼知道非空目錄會不會有文件沖突呢)，平時多看手冊還是有幫助的。
因為每個數據塊的頭部都有LSN標記，所以PostgreSQL支持數據文件的塊級增量，只備份上一次備份以來，變更過的數據塊。同樣支持恢復到任意時間點（事務粒度）。相比全量+歸檔，更節約空間。
《PostgreSQL 最佳實踐 - 塊級別增量備份(pg_rman baSEOn LSN)源碼淺析與使用》
《PostgreSQL 最佳實踐 - pg_rman 以standby為源的備份淺析》
《PostgreSQL 最佳實踐 - pg_rman 數據庫恢復示例 與 軟件限制解說》
https://github.com/postgresPRo/pg_probackup
除了數據庫本身支持的數據文件塊級增量備份，如果你使用了支持快照的文件系統或者邏輯卷管理的存儲，那么你還有一種增量備份的選擇，打快照，注意打快照時需要先執行pg_start_backup('')，讓數據庫進入在線備份狀態，打完快照執行pg_stop_backup()。
《PostgreSQL 最佳實踐 - 塊級增量備份(ZFS篇)方案與實戰》
《PostgreSQL 最佳實踐 - 塊級增量備份(ZFS篇)備份集自動校驗》
《PostgreSQL 最佳實踐 - 塊級增量備份(ZFS篇)單個數據庫采用多個zfs卷(如表空間)時如何一致性備份》
《PostgreSQL 最佳實踐 - 塊級增量備份(ZFS篇)雙機HA與塊級備份部署》
把不會變化的歷史數據存儲到阿里云提供的外部對象存儲中，即節省數據庫空間，同時對象存儲本身就是多副本的。
oss_fdw插件用法參考
https://help.aliyun.com/document_detail/44461.html
備份如果只放在數據庫的同一機房，是無法抵御單一機房的風險的，許多公司會將在異地機房有一份備份的存檔或者鏡像。
對于PostgreSQL數據庫，異地備份非常的簡便和多樣，比如
1. 方法1, 對已經在異地的流式standby節點進行備份，
2. 方法2, 通過文件系統如zfs或存儲的快照，將備份傳輸到異地機房
3. 方法3, 將本地的全量備份異步的傳輸到異地機房，同時將主機房數據庫的redo流式的傳輸到異地機房，保證兩個機房的數據延遲極低，當主機房發生險情（如地震）時，數據丟失率通常能控制在KB或者毫秒內的級別（視帶寬和業務情況，即REDO產生的速率與帶寬的匹配）。 如果你希望做到異地的0丟失，可以拉專線，使用異地同步流復制，這樣的話即使主機房完全掛掉，也不會丟數據了。
4. 方法4, 將本地機房的備份數據，異步或者通過調度的方式，定時的同步到異地機房的存儲中。
除了有效的備份，還要保證備份的有效性，例如，可以使用以下方法檢驗備份+歸檔，以及快照方法備份的有效性。
《PostgreSQL 最佳實踐 - 在線增量備份與任意時間點恢復》
《PostgreSQL 最佳實踐 - 任意時間點恢復源碼分析》
《PostgreSQL 最佳實踐 - 塊級增量備份(ZFS篇)備份集自動校驗》
除了要有日常的備份，HA，異地備份，異地容災，備份集合的校驗機制。
制定規范，養成良好的習慣也是很重要的。奉上 《DBA一族九陽神功秘籍》 希望對大家有一絲幫助。
作為DBA一族，首當其沖的是守衛數據，讓數據庫正常運轉，所以有些事情是骨子里就應該遵循的。
1. 制定并執行數據庫安全規范
2. 制定并執行數據庫管理規范
3. 制定并執行數據庫開發規范
4. 建立自動化監控系統
5. 建立自動化巡檢、備份、HA、異地容災、異地備份系統、(還有很重要的備份集可用性校驗，特別是在磁帶庫時代)
6. 制定節假日的封網機制、應急機制
這樣就建立了一道強有力的封印，可以有效的防止外族入侵。
《DBA專供 岡本003系列 - 數據庫安全第一,過個好年》
《PostgreSQL 數據庫安全指南》
《PostgreSQL 數據庫開發與管理規范》
《PostgreSQL 數據庫巡檢》
《PostgreSQL 數據庫在上市公司重要應用中的SOX審計》
1. 春節前，建議增加一次例行的巡檢，就好像我們出遠門檢查一下車子一樣。
2. 對可預知的業務數據庫、（當然還包括應用服務器等）進行擴容，這個是很有必要的，通常許多業務會在節假日時迎接高峰，例如游戲類業務、社交類業務、電商類業務等。
3. 預備一批硬件standby，以便應對春節的即時需要
4. 封網，停止變更，通常需要提前數天停止變更，減少因為變更帶來的潛在問題。
例如應用程序變更后，可能新增了一些SQL語句，這些SQL語句本身可能沒有優化好，又或者無法預知業務對這些SQL語句的請求量并發量等，導致數據庫在重大節假日存在潛在的炸彈。
5. 排班。安排好值日，做到7*24小時有DBA可以響應，保持手機暢通，同時確保值班的童鞋可以連接網絡。
6. 通常值日生在節假日期間一個人要負責的業務比平時負責的業務更廣泛，所以對值日生進行值班內容、業務的培訓也是很有必要的。
因此平時的DBA輪崗機制也是很重要的，要絕對避免這樣的現象：一個業務只有一位DBA熟悉。
7. 宣導，向公司業務方敲鑼打鼓的宣導，要進入封網期間了，請大家遵循封網規則，不要在封網期間做越界的事情（比如變更、發布）。
雖然在制度上和某些IT手段上控制了封網期間的行為，但是難免有漏網之魚，所以宣導也是很重要的。
DBA一族九陽神功 3 重大節假日中篇
1. 值班，通常分為在線和離線值班，在線和上班差不多，可能要隨時關注一些NOC平臺的指標，間歇性的填寫一些值班報告。
離線值班指被動的接收告警短信，郵件，發生問題時上線處理。
2. 交接班，交接班是非常重要的，通常上一個班的同事會發現一些異常，交代給下一位值班的同事，如果真的遇到問題響應速度和判斷效率也更高。
DBA一族九陽神功 4 重大節假日后篇
封網結束后，一切又回歸正常了。但是有一件很重要的事情別忘記了。
1. 復盤
復盤通常指對封網期間的系統狀態進行回顧，要達到幾個目的
1.1 擴容預估是否合理，同時建議反饋給業務方相應的數據
1.2 是否有故障，什么原因導致的，將來如何避免
1.3 監控系統是否存在疏漏，將來如何避免
1.4 是否有違規變更、發布，將來如何避免
新聞熱點
疑難解答
