當使用 Azure SQL Database 做為系統儲存資料的載體 , 要如何設定可以用較經濟的成本來降低資料保存的風險
這一陣子剛好新的服務單位需要導入 ISO 27001:2022 的資安規範，以往想說就是按表操課，也就沒有接觸和注意到這一塊的部分，因此利用一點時間來整理最近遇到的幾個問題。
首先是在建立資料庫的時候，我們要先注意到「備份儲存體的備援」模式，會有三種可以選擇，分別是本地、區域和異地，這個部分主要是設定Azure SQL Database 的備份資料要放在哪裡，在微軟的 Learn 上有詳細的介紹。
如果要保險就選擇越下面的選項，但價格也就越高。選擇本地就是 Azure SQL Database 所設定的等級的價格，區域就是價格乘上 1.25，而異地就是價格乘上 2，就看想要多少成本來換風險囉。
這個設定的部分除了在建立的時候可以選擇，之後也可以在 Portal 上針對每個資料庫來做調整，選擇「計算+儲存體」，就可以在設定資料的部分來做調整。
接下來就是要設定短期備份的週期，這個主要是可以用在資料庫還原的時候，您想往回多久的日期。除了資料庫設定定價層是採用 DTU 計價且設定為基本，這個週期限制最長只能七天，其他類型的週期，預設是七天，都可以設定延長到最長 35 天。
但是這個部分在 Azure SQL Database 的哪裡設定呢 ? 以前是自己管理資料庫的時候，就想說用 PowerShell 設定一下就好了，後來有朋友在詢問的時候，一時之間忽然找不到在哪裡，花費一堆時間才發現是在 Azure SQL Database 的 Server 上來做設定。
可以在右邊選單上選擇「備份」→「保留原則」，就可以看到我所建立的範例資料庫的短期備份週期是七天，但怎麼上方的「設定原則」和「移除 LTR 設定」怎麼會是取消的 ?! 那要怎麼來做設定呢 ?
其實這個部分不用緊張，當你先把資料庫選擇起來，上方的那兩個選項就會出現了，接下來就可以進行設定了。此部分一開始我也在這卡關一陣子，後來測試一下才搞清楚原來他是這樣操作的。
這裡我會習慣設定為 35 天，因為很多時候我們要追查系統的問題的時候，往往都不會是當下，此時會需要比較久之前的資料來協助釐清問題，這個就直接把拉稈移到最右邊即可。
雖然就我自己個人使用這幾年下來的經驗，絕大部分系統問題透過上述設定 PITR ( Point-In-Time Restore 時間點還原 )，就已經非常的足夠了，因為真的要遇到資料庫整個損毀不能讀取，而要透過備份檔案來復原的機會，在雲端的環境下還真的不容易發生，多半都是某些工程師不小心刪除或異動到資料，那也很少會需要用到一個月之前的資料。
但是就像很常拿來說的，「不怕一萬，只怕萬一」，因此適當的規劃 LTR ( Long-Term Retention - 長期保留 )，也是降低風險的一種方式，在跟前面 PITR 的同一個設定的下方，基本上最長可以保留 10 年，至於要怎麼設定多少週、月、年，則可以參考 Learn 上面的說明文件，裡面也有很詳細的說明相關差異。目前我是比較偷懶，就直接設定保留 260 週，我想這對我來說已經是非常足夠了。
除了上述三項設定，通常我還會在資料庫上再加上異地複本的設定，因為除了多一份保障之外，更重要的是還可以用這個來做到讀寫分離，一般來說可以看您的需要，最高可以設定到四個複本，但除非您的資料庫真的不能有任何一點閃失，而你又不能完全相信前面三項的設定，更重要的是錢不是問題，那或許是可以那樣設定。
