Hosch.id (Hosting School Indonesia)

Hosting RDM Madrasah

Hosting RDM: Kapasitas, Database, Backup & Operasional yang Terukur

Layanan untuk menjalankan Rapor Digital Madrasah secara online dengan infrastruktur, database, DNS/subdomain, HTTPS, backup, migrasi, dan dukungan teknis sesuai paket serta konfigurasi yang disepakati. Halaman ini tidak menjanjikan kapasitas, uptime, backup, RPO, atau RTO yang sama untuk setiap lingkungan.

Konsultasi Hosting RDM Lihat Paket Baca SLA

Kapasitas bukan hanya jumlah siswaConcurrent users, database, PDF, storage, dan pola akses puncak ikut menentukan kebutuhan.

Backup bersifat konfiguratifFrekuensi, retensi, dan restore mengikuti paket serta arsitektur yang digunakan.

Availability mengikuti SLAOnline access tidak berarti jaminan 24/7 tanpa downtime atau target universal.

Provider boundary dijelaskanCompute/data center dapat bergantung pada mitra infrastruktur di luar kendali langsung Hosch.id.

Hasil audit ulang: klaim pemantauan kontinu, akses tanpa henti, jadwal backup tertentu, masa retensi tertentu, atau spesifikasi server tetap tidak diperlakukan sebagai janji universal. Parameter operasional hanya berlaku bila benar-benar dicantumkan pada paket, konfigurasi, atau kesepakatan layanan.

Service scope

1. Apa yang Dimaksud Hosting RDM

Hosting RDM adalah lingkungan operasional untuk aplikasi berbasis database yang memiliki pola penggunaan berbeda antara hari biasa dan periode input/cetak rapor.

Dapat termasuk

Komponen yang dikelola sesuai paket

compute/server dan runtime aplikasi;
database MySQL/MariaDB sesuai kompatibilitas aplikasi;
DNS/subdomain dan HTTPS;
backup/restore sesuai konfigurasi;
migrasi dan verifikasi go-live;
dukungan troubleshooting dalam scope.

Tidak otomatis termasuk

Hal yang harus dikonfirmasi

resource CPU/RAM/storage tertentu;
backup harian atau retensi tertentu;
RPO/RTO numerik;
availability target tertentu;
offsite backup, dedicated resource, atau HA;
support di luar jam/ruang lingkup SLA.

Architecture & boundary

2. Arsitektur & Batas Tanggung Jawab Provider

Hosting RDM terdiri dari beberapa lapisan. Tidak semua lapisan dimiliki atau dikendalikan langsung oleh Hosch.id.

01Akses Pengguna

Guru/operator, perangkat, browser, dan koneksi internet.

02DNS & HTTPS

Domain/subdomain, resolver, sertifikat, dan routing.

03Compute

VPS/cloud runtime melalui infrastruktur yang digunakan.

04Database

Data aplikasi, query, kredensial, dan konfigurasi DB.

05Backup & Ops

Backup, restore, logging, support, dan governance.

Responsibility boundary
Lapisan	Contoh tanggung jawab Hosch.id	Dependensi di luar kendali langsung
Konfigurasi layanan	Runtime, database, DNS, HTTPS, akses, migrasi, dan perubahan yang memang berada dalam scope.	Fitur/bug aplikasi pihak ketiga dan instruksi pengguna.
Infrastruktur	Memilih/menata resource yang digunakan serta melakukan eskalasi sesuai kemampuan layanan.	Data center, hypervisor, jaringan upstream, listrik, dan kebijakan provider.
Pengguna	Memberi panduan akses dan support pada komponen yang dikelola.	Perangkat guru/operator, ISP lokal, browser, serta keamanan kredensial di sisi pengguna.

Batas peran umum tersedia pada Status & Kedudukan Layanan; gambaran lintas-lapisan ada pada Arsitektur Infrastruktur.

Capacity planning

3. Kapasitas: Jumlah Pengguna Bukan Satu-Satunya Ukuran

Jumlah siswa/pengguna adalah indikator awal untuk screening. Kapasitas aktual perlu mempertimbangkan concurrent sessions, database, proses PDF, storage, I/O, dan pola akses pada periode puncak.

Faktor yang digunakan untuk menentukan kapasitas
Indikator	Mengapa penting	Tindakan
Jumlah pengguna total	Menggambarkan skala institusi, tetapi tidak menunjukkan beban pada satu waktu.	Dipakai sebagai screening awal dan pemetaan paket.
Pengguna simultan	Lebih dekat dengan beban nyata CPU, memory, session, dan query.	Perkirakan terutama saat input nilai/verifikasi.
Cetak PDF	Proses massal dapat menambah CPU, memory, I/O, dan waktu eksekusi.	Uji pada sampel beban sebelum peak season.
Database	Ukuran, pertumbuhan, indeks, dan query memengaruhi performa.	Evaluasi kondisi DB, bukan hanya jumlah akun.
Storage & I/O	Upload, cache, temporary files, dan backup membutuhkan ruang serta throughput.	Sisakan headroom dan pantau pertumbuhan.
Pola musim rapor	Beban dapat naik tajam pada periode tertentu.	Evaluasi kapasitas sebelum periode puncak.

Tidak ada spesifikasi CPU/RAM universal di halaman ini. Baseline numerik pada versi sebelumnya berisiko dianggap sebagai jaminan performa. Paket awal dapat menggunakan jumlah pengguna sebagai indikator, tetapi resource final ditentukan setelah melihat workload dan konfigurasi aktual.

Database & runtime

4. Database Management & Runtime

RDM bergantung pada aplikasi, runtime PHP, database, file storage, dan konfigurasi yang saling terkait. Nilai parameter teknis perlu mengikuti versi aplikasi serta kondisi server, bukan angka yang dianggap universal.

Database

Kontrol yang relevan

MySQL/MariaDB sesuai kompatibilitas aplikasi;
kredensial dan hak akses dibatasi sesuai kebutuhan;
monitor query, ukuran DB, dan pertumbuhan data;
verifikasi integritas data setelah import/restore;
hindari perubahan struktur tanpa backup dan rencana rollback.

Runtime

Konfigurasi berbasis kebutuhan

versi PHP mengikuti kompatibilitas RDM;
memory/time limits disesuaikan dengan workload;
ekstensi yang dibutuhkan aplikasi diverifikasi;
log error digunakan untuk diagnosis;
parameter tidak dinaikkan tanpa memahami bottleneck.

Audit V3 menghapus “magic numbers” PHP/DB sebagai standar umum. Nilai konfigurasi spesifik tetap dapat dipakai pada environment tertentu setelah pengujian, tetapi tidak dijanjikan cocok untuk semua versi dan deployment RDM.

Backup, restore & continuity

5. Backup, Restore, RPO & RTO

Backup adalah mitigasi risiko, bukan jaminan bahwa semua perubahan data selalu dapat dipulihkan tanpa kehilangan.

Backup & restore

Yang perlu dikonfirmasi

objek yang dibackup: database, files, atau keduanya;
frekuensi backup dan periode retensi;
lokasi/media backup bila relevan;
siapa yang dapat meminta restore;
cara verifikasi hasil restore.

RPO / RTO

Tidak diasumsikan otomatis

RPO menggambarkan toleransi kehilangan data berdasarkan titik pemulihan yang tersedia. RTO menggambarkan target waktu pemulihan layanan. Hosch.id tidak menetapkan RPO/RTO numerik universal pada halaman ini; angka hanya berlaku bila dinyatakan pada paket atau kesepakatan terkait.

Tidak ada zero-data-loss guarantee. Restore bergantung pada keberadaan dan integritas titik backup, waktu insiden, perubahan setelah backup terakhir, aplikasi, serta kondisi sumber. Baca Kebijakan Retensi Data dan SLA.

Availability & observability

6. Availability, Monitoring & SLA

RDM dirancang untuk akses online, tetapi “online” bukan sinonim dengan jaminan tanpa downtime. Target availability hanya berlaku jika paket/kesepakatan secara eksplisit mencakupnya.

Availability

Target bersyarat

Gunakan SLA untuk definisi qualifying downtime, maintenance, pengecualian, third-party dependency, dan remedies.

Monitoring teknis

Observasi sesuai tool/provider

Log, resource usage, dan health signal dapat dipantau pada komponen yang tersedia; cakupannya tidak identik pada setiap paket.

Status publik

Bukan dashboard live

Status & Changelog adalah log transparansi statis, bukan monitoring server real-time.

Migration

7. Migrasi RDM: Backup, Validasi, Cutover & Rollback

Migrasi yang aman bukan sekadar memindahkan file. Kondisi server sumber, versi aplikasi, database, uploads/assets, domain, DNS, dan waktu cutover perlu diverifikasi.

01Inventaris

Versi aplikasi/PHP, domain, database, files, dan akses.

02Backup sumber

Ekspor DB dan file yang diperlukan lalu verifikasi hasil.

03Restore test

Uji pada tujuan/staging bila memungkinkan sebelum cutover.

04Konfigurasi

Sesuaikan environment, URL, DB, permission, dan HTTPS.

05Validasi

Uji login, data, upload, dan cetak rapor.

06Go-live

Cutover pada waktu beban rendah dan pertahankan opsi rollback.

Hindari migrasi pada periode input/cetak rapor aktif bila dapat dijadwalkan. Setelah migrasi, bandingkan record/data yang relevan dan jangan menghapus sumber sebelum hasil diverifikasi sesuai rencana perubahan.

Security & privacy

8. Keamanan & Privasi: Kontrol Proporsional, Bukan Security Guarantee

HTTPS, firewall, access control, logging, dan backup dapat mengurangi risiko, tetapi tidak menghilangkan seluruh kemungkinan insiden.

Kontrol teknis

Contoh kontrol dalam scope

HTTPS/TLS pada endpoint yang dikonfigurasi;
pembatasan akses administratif;
firewall/rules sesuai environment;
pengelolaan kredensial dan perubahan konfigurasi;
logging/monitoring yang tersedia pada platform.

Data & peran

Controller / processor ditentukan per aktivitas

Hosting tidak otomatis menjadikan Hosch.id Pengendali seluruh Data Pribadi dalam RDM. Peran para pihak mengikuti siapa yang menentukan tujuan/kendali pemrosesan dan siapa yang memproses atas instruksi pihak lain.

Detail berada pada Kebijakan Keamanan Informasi dan Kebijakan Pelindungan Data Pribadi.

Peak season

9. Operasional Menjelang Musim Rapor

Peak season perlu diperlakukan sebagai periode perubahan terkontrol, bukan saat untuk eksperimen konfigurasi besar.

Sebelum puncak

Review kapasitas

Periksa resource, growth database, storage, antrean PDF, error log, backup, dan perubahan yang tertunda.

Saat puncak

Minimalkan perubahan

Tunda perubahan non-prioritas, pantau gejala bottleneck, dan dokumentasikan tindakan yang dilakukan.

Sesudah puncak

Evaluasi

Tinjau error, kapasitas, kebutuhan tuning, backup tambahan, serta tindakan korektif sebelum siklus berikutnya.

Troubleshooting

10. Diagnosis Awal Tanpa Mengubah Sistem Secara Spekulatif

Gejala yang sama dapat memiliki penyebab berbeda. Gunakan log dan bukti terlebih dahulu sebelum menaikkan resource atau mengubah konfigurasi.

Contoh diagnosis awal
Gejala	Yang diperiksa	Langkah awal
Error 500	Error log, PHP/runtime, permission, aplikasi, resource.	Identifikasi error spesifik sebelum mengubah limit.
Database connection error	Kredensial, host DB, service database, resource, konfigurasi.	Verifikasi koneksi dan log; jangan mengirim password melalui kanal biasa.
Cetak PDF gagal/lambat	Log, temporary storage, memory/time limit, extension, jumlah job.	Uji satu proses dan bandingkan dengan peak load.
Login/session bermasalah	URL/domain, HTTPS, cookies/session, waktu server, konfigurasi aplikasi.	Validasi URL dan session sebelum menambah resource.

Panduan yang lebih teknis sebaiknya ditempatkan pada Panduan Teknis dan SOP Operator RDM, bukan diduplikasi penuh pada halaman layanan.

Implementation evidence

11. Konteks Implementasi yang Menjadi Dasar Praktik Operasional

Pengalaman implementasi digunakan sebagai konteks untuk mengembangkan prosedur, bukan sebagai jaminan bahwa setiap institusi akan memiliki performa atau konfigurasi yang sama.

Inventaris September 2026

120+ endpoint / hostname

Sumber halaman mencatat inventaris internal lebih dari 120 domain, subdomain, dan endpoint aplikasi, termasuk lebih dari 80 endpoint terkait RDM.

Interpretasi angka

Endpoint bukan pelanggan

Angka tersebut tidak mewakili jumlah institusi atau pelanggan unik. Data publik disajikan agregat dan dianonimkan.

Lihat metodologi dan Jejak Implementasi Infrastruktur Hosch.id.

Decision FAQ

12. FAQ Singkat Hosting RDM

Jawaban berikut membantu keputusan awal; detail harga, SLA, retensi, dan keamanan tetap mengikuti dokumen khusus.

Apakah Hosting RDM berarti layanan dijamin aktif 24/7 tanpa downtime?

Tidak. RDM dirancang untuk akses online, tetapi target availability hanya berlaku jika dicantumkan dalam paket/SLA. Maintenance, provider dependency, dan pengecualian lain dibaca pada SLA.

Apakah jumlah siswa menentukan paket secara otomatis?

Tidak. Jumlah pengguna adalah indikator awal. Concurrent users, database, proses PDF, storage, pola penggunaan, dan kondisi aplikasi dapat mengubah kebutuhan aktual.

Apakah backup berarti tidak mungkin kehilangan data?

Tidak. Backup mengurangi risiko, tetapi titik pemulihan bergantung pada frekuensi, retensi, integritas backup, dan waktu insiden. Tidak ada zero-data-loss guarantee universal.

Berapa RPO dan RTO Hosting RDM?

Tidak ada RPO/RTO numerik universal pada halaman ini. Jika dibutuhkan, target tersebut harus dinyatakan dalam paket atau kesepakatan layanan yang relevan.

Butuh menentukan kapasitas atau memigrasikan RDM?

Sampaikan perkiraan pengguna, kondisi database, server/hosting saat ini, pola akses, domain/subdomain, kebutuhan backup, dan target waktu. Hosch.id dapat membantu memetakan scope sebelum perubahan dilakukan.

Buka Bantuan Admin