Tutorial

Saat Update Membuat Situs Klien Rusak: Memulihkan Satu Tenant Tanpa Menyentuh yang Lain

Tim GrabWP
· 5 min read · Direview oleh Tim GrabWP

Setiap freelancer yang mengelola situs klien pasti pernah mendapat pesan ini: “situs down dan saya tidak menyentuh apa pun.” Biasanya memang ada yang berubah, baik itu plugin yang auto-update, editan yang salah, perubahan theme yang merusak tampilan, dan sekarang klien menunggu sementara Anda mencari cara untuk mengembalikannya. Jika satu-satunya pilihan Anda adalah membangun ulang secara manual atau melakukan restore backup server penuh yang juga me-rollback klien Anda yang lain, satu situs yang rusak bisa menjadi malapetaka bagi sisa hari Anda.

Panduan ini membahas akhir dari siklus hidup situs klien, yaitu pemulihan: mengembalikan satu situs klien ke kondisi baik yang diketahui dengan cepat, tanpa mengganggu apa pun yang Anda kelola. Ini adalah jaring pengaman di bawah alur kerja pemeliharaan satu dashboard, karena alasan Anda bisa melakukan update dengan percaya diri adalah karena Anda bisa melakukan rollback dengan bersih.

Mengapa pemulihan berisiko pada setup bersama

Cara sebagian besar freelancer melakukan hosting klien membuat pemulihan menjadi pertaruhan yang sangat berisiko, antara pulih semua atau gagal semua:

  • Satu backup server mencakup semuanya. Jika semua klien Anda berbagi satu instalasi dan Anda me-restore backup penuh tadi malam, Anda juga me-rollback perubahan dari setiap klien lain pada hari ini. Memperbaiki satu situs malah merusak empat situs lainnya.
  • Perbaikan manual berjalan lambat di bawah tekanan. Membangun ulang situs yang rusak secara manual, atau mencari tahu update plugin mana yang menyebabkan kegagalan, adalah tugas yang sangat tidak tepat untuk dilakukan saat klien sedang menunggu dan memperhatikan.
  • Anda mungkin tidak memiliki titik restore terbaru. Jika backup dilakukan manual, salinan bagus terakhir mungkin sudah berusia seminggu, jadi pemulihan berarti kehilangan hasil kerja nyata meskipun prosesnya berhasil.

Tujuannya adalah untuk memulihkan satu situs klien dari backup terbaru dalam hitungan menit, sementara setiap situs lain yang Anda kelola tetap persis seperti sebelumnya.

Pulihkan satu tenant, biarkan yang lain

GrabWP Tenancy Pro melakukan hosting setiap klien sebagai tenant yang terisolasi dengan database dan kontennya sendiri, dan backup serta restore-nya berjalan per tenant. Isolasi tersebut adalah poin utamanya selama pemulihan: me-restore satu klien hanya akan menyentuh klien tersebut.

Anda sudah memiliki titik restore

Titik restore per tenant tercantum dalam manajer backup GrabWP Tenancy Pro

Jika Anda mengikuti alur kerja pemeliharaan dan menyalakan backup otomatis terjadwal, pemulihan Anda dimulai dari posisi yang menguntungkan. Backup tersebut memberi Anda titik restore terbaru pada jadwal yang Anda pilih, mulai dari setiap jam hingga setiap bulan, dengan salinan lama yang dipangkas secara otomatis. Saat situs rusak, Anda tidak perlu berebut mencari backup, Anda hanya perlu memilih backup terbaru mana yang akan di-restore.

Lakukan rollback dari backup milik tenant sendiri

Melakukan rollback satu tenant dari backup miliknya sendiri tanpa memengaruhi situs klien lain

Dari layar restore tenant, Pro memungkinkan Anda mencantumkan, mengunduh, menghapus, dan me-restore backup on-disk sebelumnya, dengan tab restore untuk memilih backup yang ada atau mengunggah arsip baru. Anda memilih backup terakhir yang diketahui baik dan menjalankan restore. Alur kerja restore 8 langkah mencakup database, unggahan, konten, dan konfigurasi tenant, dengan antarmuka progres AJAX sehingga Anda bisa melihat setiap langkah selesai daripada menebak apakah prosesnya berhasil.

Karena restore tersebut dibatasi hanya untuk tenant itu, tidak ada klien Anda yang lain yang terpengaruh. Situs yang rusak kembali ke kondisi berfungsinya, dan sisa klien Anda tetap berjalan seperti biasa.

Pulihkan bahkan melintasi jenis database

Restore Pro berfungsi melintasi jenis database, jadi tenant bisa di-restore antara shared MySQL, dedicated MySQL, dan SQLite. Jika Anda memindahkan klien di antara tata letak database selama pemeliharaan, backup masih dapat digunakan. Situs tersebut tidak terkunci pada konfigurasi yang sama persis seperti saat di-backup.

Ketika server itu sendiri yang menjadi masalah

Backup terjadwal dapat dikirim ke penyimpanan objek yang kompatibel dengan S3 setelah setiap proses berjalan, dengan isolasi per tenant di sisi penyimpanan. Jika masalahnya lebih besar dari sekadar update yang buruk, misalnya masalah disk atau masalah host, Anda masih memiliki salinan offsite dari setiap situs klien untuk di-restore, daripada bergantung pada server yang sama yang baru saja bermasalah.

Buku panduan pemulihan yang bisa Anda percaya

Satukan semua bagiannya dan pemulihan menjadi hal yang rutin, bukan lagi hal yang menakutkan:

  1. Konfirmasi ruang lingkupnya. Hanya satu situs klien yang terpengaruh, karena tenant diisolasi. Anda tidak menyentuh siapa pun.
  2. Pilih titik restore. Backup terjadwal berarti salinan bagus terbaru sudah ada di disk atau di S3.
  3. Restore tenant tersebut. Jalankan restore 8 langkah dari layar restore tenant dan perhatikan sampai selesai.
  4. Verifikasi dan lanjutkan. Periksa apakah situs klien berfungsi, beri tahu klien bahwa masalahnya sudah ditangani, dan klien Anda yang lain tidak akan pernah tahu bahwa ada sesuatu yang terjadi.

Pengalaman klien hanyalah downtime singkat dan perbaikan cepat, bukan hari yang terbuang, dan risiko Anda terbatas pada satu situs, bukan seluruh instalasi Anda.

Pemulihan menutup siklus hidup

Kemampuan untuk memulihkan satu klien dengan bersih adalah hal yang membuat sisa alur kerja Anda menjadi aman. Anda bisa menggandakan situs pemula untuk klien baru, memelihara setiap situs dari satu dashboard, dan menyerahkan situs yang sudah selesai tanpa penguncian, semuanya dengan keyakinan bahwa update yang buruk hanyalah rollback yang memakan waktu beberapa menit, bukan sebuah bencana. Secara keseluruhan, proses onboarding, pemeliharaan, penyerahan, dan pemulihan memungkinkan Anda menjalankan seluruh daftar klien dari satu instalasi tanpa risiko yang terus membesar seiring dengan bertambahnya jumlah klien.

Mengelola situs klien dan menginginkan backup per tenant yang bisa Anda restore dalam hitungan menit tanpa menyentuh klien Anda yang lain? Paket Pro menyertakan backup terjadwal, restore per tenant, dan pemulihan lintas database mulai dari $9.99/month.

Pertanyaan yang sering diajukan

Bisakah saya melakukan restore satu situs klien tanpa memengaruhi klien saya yang lain?
Ya. Di GrabWP Tenancy Pro, setiap tenant diisolasi dengan database dan kontennya masing-masing, dan proses restore berjalan per tenant. Anda melakukan rollback pada klien yang bermasalah ke salah satu backup miliknya sendiri sementara setiap tenant lain di instalasi tersebut tetap berjalan tanpa tersentuh.
Seberapa cepat saya bisa melakukan rollback setelah update yang buruk?
Jika backup terjadwal aktif, Anda sudah memiliki titik restore terbaru. Dari layar restore tenant, Anda memilih backup on-disk yang ada dan menjalankan restore 8 langkah dengan antarmuka progres, sehingga pemulihan hanya butuh beberapa menit pengawasan dan bukan perbaikan manual.
Apakah saya perlu menyimpan file backup terpisah di suatu tempat untuk pemulihan?
Versi Pro mencantumkan, mengunduh, menghapus, dan melakukan restore backup on-disk sebelumnya dari admin, dan backup terjadwal dapat disimpan ke penyimpanan yang kompatibel dengan S3. Anda melakukan restore dari backup yang ada secara langsung, dan Anda juga memiliki salinan offsite jika server itu sendiri yang bermasalah.
Bisakah saya memulihkan sebuah situs meskipun jenis database-nya berubah?
Ya. Fitur restore Pro berfungsi lintas jenis database, jadi Anda bisa melakukan restore antara shared MySQL, dedicated MySQL, dan SQLite. Sebuah tenant tidak terkunci pada tata letak database yang sama persis seperti saat di-backup.

Editorial standards: Our content is written by WordPress experts with hands-on multi-tenancy experience. Articles are fact-checked and regularly updated to ensure accuracy.