Menjelaskan tujuan waktu pemulihan dan tujuan titik pemulihan
Memahami waktu pemulihan dan tujuan titik pemulihan sangat penting untuk rencana ketersediaan tinggi dan pemulihan bencana (HADR) Anda karena ini adalah fondasi untuk solusi ketersediaan apa pun.
Tujuan Waktu Pemulihan
Tujuan Waktu Pemulihan (RTO) merupakan jumlah waktu maksimum yang tersedia untuk membawa sumber daya online setelah pemadaman atau adanya masalah. Jika proses tersebut memakan waktu lebih lama dari RTO, akan ada konsekuensi seperti denda finansial, pekerjaan yang terhambat, dan sebagainya. RTO dapat ditentukan untuk seluruh solusi, yang mencakup semua sumber daya, serta untuk komponen individual seperti database. dan instans SQL Server.
Tujuan Titik Pemulihan
Tujuan Titik Pemulihan (RPO) merupakan titik waktu di mana database seharusnya sudah pulih dan setara dengan jumlah maksimum kehilangan data yang bersedia diterima oleh pebisnis. Misalnya, VM IaaS yang berisi SQL Server mengalami pemadaman pada pukul 10:00 dan database dalam instans SQL Server memiliki Tujuan Titik Pemulihan 15 menit. Tidak peduli fitur atau teknologi apa yang digunakan untuk mengembalikan instans dan database tersebut, harapannya adalah nilai data yang hilang tidak lebih daripada 15 menit. Hal ini berarti database dapat dipulihkan ke keadaan pada jam 09:45 atau lebih baru untuk memastikan kehilangan data minimal atau memenuhi RPO. Mungkin ada faktor-faktor yang menentukan apakah RPO tersebut dapat dicapai.
Menentukan Tujuan Waktu dan Titik Pemulihan
RTO dan RPO didorong oleh persyaratan bisnis tetapi juga didasarkan pada berbagai faktor teknologi dan lainnya, seperti keterampilan dan kemampuan administrator (bukan hanya DBA). Meskipun bisnis mungkin menginginkan tidak adanya downtime maupun kehilangan data, hal tersebut tidaklah realistis ataupun dapat terjadi dikarenakan berbagai alasan. Menentukan solusi RTO dan RPO milik Anda seharusnya dilakukan dengan diskusi terbuka dan jujur antara semua pihak yang terlibat.
Salah satu rasio aspek penting untuk RTO dan RPO adalah mengetahui biaya downtime. Jika Anda menentukan angka tersebut dan efek keseluruhan yang tidak berfungsi atau tidak tersedia untuk bisnis, lebih mudah untuk menentukan solusi. Misalnya, jika suatu bisnis dapat mengalami kerugian 10.000 per jam atau mendapat denda dari lembaga pemerintah jika sesuatu tidak dapat diproses, itu adalah cara terukur untuk membantu menentukan RTO dan RPO. Pengeluaran untuk menemukan sebuah solusi harus proporsional dengan jumlah, atau biaya, dari waktu yang terbuang. Jika solusi HADR Anda berharga $X, tetapi alih-alih beberapa jam ternyata anda hanya terpengaruh selama beberapa detik saja ketika masalahnya terjadi, biaya pin otomatis telah tertutupi.
Dari sudut sikap nonbusiness, RTO harus didefinisikan pada tingkat komponen (misalnya, SQL Server) serta untuk seluruh arsitektur aplikasi. Kemampuan untuk pulih dari pemadaman hanya sebaik tautan terlemahnya. Misalnya, jika SQL Server dan databasenya dapat dibawa online dalam lima menit tetapi server aplikasi membutuhkan 20 menit untuk melakukan hal yang sama, RTO keseluruhan akan menjadi 20 menit, bukan lima. Lingkungan SQL Server masih dapat memiliki waktu RTO lima menit; walaupun begitu hal tersebut masih tidak akan mengubah waktu keseluruhan untuk pulih.
Tujuan Titik Pemulihan secara khusus menangani data dan secara langsung memengaruhi desain solusi HADR apa pun serta kebijakan dan prosedur administratif. Fitur yang digunakan harus mendukung RTO dan RPO yang ditentukan. Misalnya, jika pencadangan log transaksi dijadwalkan setiap 30 menit tetapi ada RPO 15 menit, database hanya dapat dipulihkan ke cadangan log transaksi terakhir yang tersedia yang dalam kasus terburuk adalah 30 menit yang lalu. Waktu ini mengasumsikan tidak ada masalah lain dan cadangan telah diuji dan diketahui ternyata baik. Meskipun sulit untuk menguji setiap cadangan yang dihasilkan untuk setiap database di lingkungan Anda, cadangan hanyalah file pada sistem berkas. Tanpa melakukan setidaknya pemulihan berkala, tidak ada jaminan mereka baik. Menjalankan pemeriksaan selama proses pencadangan setidaknya dapat memberi Anda sedikit ketenangan.
Fitur khusus yang digunakan, seperti Grup Ketersediaan AlwaysOn (AG) atau Instans kluster failover Grup Ketersediaan AlwaysOn (FCI) juga akan memengaruhi RTO dan RPO Anda. Tergantung pada bagaimana fitur dikonfigurasi, solusi IaaS atau PaaS mungkin atau mungkin tidak secara otomatis gagal ke lokasi lain, yang dapat mengakibatkan waktu henti yang lebih lama. Dengan mendefinisikan RTO dan RPO, solusi teknis yang mendukung persyaratan tersebut dapat dirancang dengan mengetahui kelonggaran waktu dan kehilangan data. Jika hak tersebut ternyata tidak realistis, RTO dan RTO harus disesuaikan secara demikian. Misalnya, jika RTO yang diinginkan dua jam tetapi pencadangan akan memakan waktu tiga jam untuk disalin ke server tujuan untuk pemulihan, RTO pun akan terlewatkan. Jenis faktor ini harus diperhitungkan saat menentukan RTO dan RPO Anda.
Harus ada RTO dan RPO yang telah ditentukan untuk HA dan DR. HA dianggap sebagai peristiwa terlokalisasi yang dapat dipulihkan dengan lebih mudah. Salah satu contoh ketersediaan tinggi adalah AG yang secara otomatis gagal dari satu replika ke replika lainnya dalam wilayah Azure. Itu mungkin memakan waktu beberapa detik, dan pada saat itu, Anda harus memastikan bahwa aplikasi dapat terhubung setelah failover. Waktu henti SQL Server akan minimal. Sebuah RTO atau RPO lokal berpotensi dapat diukur dalam hitungan menit tergantung pada sifat kritis dari solusi atau sistem.
DR akan sama seperti memunculkan pusat data yang sama sekali baru. Ada banyak potongan dari teka-teki; SQL Server hanyalah salah satu komponen. Membuat semuanya online mungkin memakan waktu berjam-jam atau lebih lama. Inilah sebabnya mengapa RTO dan RPO dipisah. Meskipun banyak teknologi dan fitur yang digunakan untuk HA dan DR adalah sama, tingkat upaya dan waktu yang diperlukan mungkin tidak.
Semua RTO dan RPO harus didokumentasikan secara formal dan direvisi secara berkala atau sesuai kebutuhan. Setelah didokumenkan, Anda kemudian dapat mempertimbangkan teknologi dan fitur apa yang dapat Anda gunakan untuk arsitektur.