Backup Database: Im/Export MySQL WordPress Laravel Joomla

Backup database adalah salinan data MySQL/MariaDB situs Anda — konten, pengguna, pesanan, opsi — yang dipakai untuk import atau restore bila migrasi gagal, server down, atau file rusak. Untuk WordPress, Laravel, dan Joomla, jalur aman meliputi export via phpMyAdmin atau mysqldump, simpan eksternal, lalu import lewat CLI bila database besar.

Banyak pemilik situs di Indonesia stuck di titik yang sama: backup sudah jalan, restore malah blank putih. Penyebabnya hampir selalu bukan “plugin jahat”, melainkan prefix, charset, atau URL yang tidak cocok setelah import. Panduan ini ditulis untuk admin yang punya — atau tidak punya — akses SSH.

Mengapa Backup Database Jadi Prioritas Perawatan Website?

Kerusakan website kerap berakar di database, bukan hanya tema atau plugin. Satu query salah, charset tidak cocok, atau tabel corrupt bisa membuat homepage kosong sementara file PHP masih utuh. Lantaran itu, backup database masuk prioritas yang sama dengan update keamanan — bedanya, Anda menyimpan state data, bukan hanya kode.

Empat alasan admin serius tidak melewatkan backup database:

• Integritas — data tetap konsisten; tidak ada baris setengah import.
• Recoverability — ada titik pulih bila hack atau human error.
• Performance — setelah backup, Anda bisa bersihkan revisions atau transients dengan risiko lebih rendah.
• Compatibility — charset, collation, dan prefix tetap selaras saat pindah hosting.

Momen rawan: migrasi hosting, upgrade major WordPress/Laravel, gabung staging ke production, atau cleanup pasca malware. Operasi backup/import ini satu lapisan perawatan teknis; untuk update rutin, monitoring, dan SEO on-page holistik, tim internal sering melibatkan vendor — topik itu kami pisahkan agar fokus tetap di MySQL. Setelah migrasi hosting, error permission admin WordPress sering muncul — lihat panduan error WordPress pasca migrasi sebagai langkah lanjutan bila restore sudah jalan tapi login gagal.

Backup Database Website: Definisi, Struktur, dan Istilah Dasar

Definisi Database pada Website

Database website = penyimpanan terstruktur yang diakses aplikasi (WordPress core, Laravel app, Joomla CMS) lewat driver MySQL/MariaDB. Bedakan tiga level:

• Database server — proses MySQL yang berjalan di hosting/VPS.
• Database (schema) — wadah bernama, contoh: wp_produksi atau laravel_app.
• Tabel — kumpulan baris & kolom; WordPress punya wp_posts, Laravel punya users, Joomla punya #__content (prefix runtime).

Analogi singkat: server = gedung, database = lantai, tabel = ruangan, baris = arsip per record.

MySQL dan MariaDB mendominasi stack WordPress, Laravel, dan Joomla di hosting Indonesia. PostgreSQL jarang dipakai untuk CMS mainstream — bila Anda lihat DB_CONNECTION=pgsql di Laravel, prosedur dump beda (pg_dump, bukan mysqldump). Artikel ini fokus MySQL/MariaDB karena itulah yang paling sering admin hadapi saat backup database website produksi.

Struktur Database — Tabel, Kolom, Index, Relasi

Setiap tabel punya kolom bertipe (INT, VARCHAR, LONGTEXT, dll.), primary key, dan sering foreign key antar tabel. Index mempercepat query — namun juga memengaruhi ukuran dump saat backup database.

Storage engine matter: InnoDB (default modern) mendukung transaksi; backup aman memakai --single-transaction pada mysqldump. MyISAM (legacy) locking table saat dump — restore besar bisa lock lebih lama.

Charset, Collation, dan Dampaknya saat Import Setelah Melakukan Backup Database

Project baru sebaiknya memakai utf8mb4 + utf8mb4_unicode_ci agar emoji dan karakter Indonesia aman. Import dump utf8 lama ke server utf8mb4 kadang menghasilkan karakter � di konten. Sebelum import database MySQL antar hosting, samakan charset di export — Custom export phpMyAdmin memungkinkan pilihan eksplisit.

utf8mb4_unicode_ci vs utf8mb4_general_ci: unicode_ci sorting lebih akurat untuk bahasa dengan aksen; general_ci sedikit lebih cepat tapi bisa salah urut. Untuk situs Indonesia tanpa kebutuhan sorting locale kompleks, keduanya cukup aman — yang kritis adalah **utf8mb4**, bukan utf8 tiga-byte lama.

Cek charset database live:

SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME
FROM information_schema.SCHEMATA
WHERE SCHEMA_NAME = 'NAMA_DATABASE';

WordPress menyimpan widget, theme mod, dan opsi plugin dalam format serialized PHP di tabel wp_options. Satu byte salah setelah search-replace URL manual = widget hilang atau customizer blank. Itulah alasan restore WordPress selalu pakai tool khusus (wp search-replace, Interconnect/IT Search Replace DB) — bukan editor teks biasa.

Ukuran Database — Tabel yang Sering Membengkak

Sebelum backup database, cek tabel terbesar lewat phpMyAdmin atau query:

SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'NAMA_DATABASE'
ORDER BY size_mb DESC
LIMIT 10;

WordPress: wp_postmeta, wp_options (transients), wp_posts (revisions). WooCommerce: wp_woocommerce_order_itemmeta. Laravel: tabel log/job queue bila tidak di-prune. Joomla: #__session dan cache. Tabel log membengkak ≠ selalu corrupt — tapi dump dan restore jadi lambat.

Konfigurasi Database WordPress, Laravel, dan Joomla

Backup database tanpa catat config = restore setengah mati. Setiap platform menyimpan kredensial di file berbeda.

Config Penting Saat Backup Database WordPress — wp-config.php dan Table Prefix

Prefix bukan lapisan keamanan — hanya namespace. Tabel inti: wp_posts, wp_postmeta, wp_options, wp_users. Jangan ganti prefix tanpa rename semua tabel. Untuk backup database WordPress via plugin, pastikan plugin ikut backup prefix yang sama.

WP-CLI mempercepat backup dan restore tanpa browser:

wp db export ~/backup-wp-$(date +%F).sql
wp db import ~/backup-wp-2026-08-08.sql
wp search-replace 'https://staging.domain.com' 'https://domain.com' --all-tables

Perintah search-replace aman untuk serialized data — beda dengan replace manual di phpMyAdmin. Tema custom modern via Twig dan Timber tetap bergantung pada struktur tabel standar WordPress; backup database WordPress tidak berubah meski templating beda.

Backup Database Laravel — .env dan Migration

Schema Laravel dikontrol migration. Migrasi database Laravel lewat php artisan migrate beda artinya dengan import SQL dump mentah. migrate:fresh di production tanpa backup = risiko hilangnya data live. Backup database Laravel idealnya: dump SQL + folder database/migrations + file .env (simpan terenkripsi).

Restore database Laravel setelah import dump:

1. Import SQL ke database kosong.
2. Pastikan .env menunjuk ke DB yang benar.
3. Jalankan php artisan config:clear dan cache:clear.
4. Cek php artisan migrate:status — bila ada migration pending, evaluasi dulu jangan asal migrate.

Queue yang memakai database driver (jobs table) ikut ter-backup — restore lama bisa memicu job stale. Truncate tabel jobs bila yakin tidak ada worker penting. Proyek PHP custom sering butuh bantuan coding saat schema kompleks — konteks serupa dibahas di halaman jasa joki coding PHP Laravel WordPress ketika restore gagal karena mismatch migration.

Joomla — configuration.php

Joomla menyimpan $host, $user, $password, $db, dan $dbprefix (default jos_) di configuration.php. Backup lengkap = database + folder /images + file config — bukan SQL saja.

Setelah restore database Joomla, periksa $live_site dan $secret di configuration.php. Extension cache kadang conflict — clear cache dari admin setelah import. Multi-language Joomla punya tabel tambahan; partial export tanpa tabel terkait = menu hilang sebagian.

Tabel Perbandingan Cepat

Backup Database — Internal vs Eksternal

Definisi Backup Internal

Backup internal = salinan yang tetap berada di infrastruktur yang sama dengan server live: backup harian cPanel, snapshot VPS, folder /wp-content/backups/, atau file dump di /home/user/backups/. Cepat dan murah — namun bila server kena ransomware atau hard disk mati, backup internal ikut hilang.

Contoh skenario internal-only yang gagal total: VPS provider kebakaran datacenter (langka, tapi pernah terjadi di luar negeri); akun hosting compromised, attacker hapus backup lokal sebelum deface; cron backup menulis ke disk yang sama dengan MySQL data — disk penuh, dump corrupt 0 KB. Internal tetap berguna untuk restore cepat same-day, asal **bukan** satu-satunya salinan.

Definisi Backup Eksternal

Backup eksternal = salinan di lokasi terpisah: laptop, NAS, Google Drive, S3, Backblaze. Rule 3-2-1 versi pemula: tiga salinan, dua media berbeda, satu offsite. Tanpa eksternal, backup database Anda belum punya cadangan yang benar-benar independen.

Praktik yang kami lihat di klien korporat Indonesia: dump harian tetap di folder /backup server yang sama, lalu satu kali per bulan admin unduh ke laptop pribadi. Itu sudah lebih baik dari nol — namun laptop hilang atau akun hosting kena suspend, dua salinan bisa hilang bersamaan. Offsite cloud dengan enkripsi (client-side bila memungkinkan) menutup celah itu.

Rotasi eksternal sederhana: simpan 4 minggu dump mingguan + 3 dump bulanan. Label file dengan tanggal ISO (2026-08-08-wp-prod.sql.gz) agar restore tidak salah pilih versi.

Metode Backup Tanpa SSH

Untuk cara backup website WordPress tanpa terminal:

1. phpMyAdmin → Export — Custom, format SQL, centang gzip bila DB >20 MB.
2. cPanel Backup Wizard — unduh archive database.
3. Plugin — UpdraftPlus, Duplicator; perhatikan limit ukuran di shared hosting.

Checklist validasi: ukuran file ≠ 0 KB; buka .sql — ada CREATE TABLE; catat versi CMS dan charset.

Plugin WordPress populer untuk backup database tanpa SSH:

• UpdraftPlus — jadwalkan backup otomatis ke Google Drive/Dropbox; restore dari admin.
• Duplicator — paket migrasi (DB + file); cocok pindah hosting kecil-menengah.
• All-in-One WP Migration — drag-drop; perhatikan limit ukuran di versi gratis.

Trade-off plugin: mudah, tapi backup besar bisa timeout di shared hosting. Kombinasi terbaik untuk UMKM: plugin untuk cadangan harian + export manual phpMyAdmin bulanan ke eksternal.

Metode Backup Database dengan SSH — mysqldump

MySQL backup database via CLI lebih andal untuk DB besar. Perintah dasar:

# Backup standar
mysqldump -u USER -p DATABASE > backup.sql

# DB besar — InnoDB, compressed
mysqldump -u USER -p --single-transaction --quick DATABASE | gzip > backup.sql.gz

# WordPress via WP-CLI
wp db export backup-$(date +%F).sql

Flag penting: --single-transaction (konsisten tanpa lock panjang), --quick (row-by-row, hemat RAM), --routines bila ada stored procedure. Untuk backup database mysql otomatis, pasang cron:

0 2 * * * mysqldump -u USER -p'PASS' DB | gzip > /backup/db-$(date +\%F).sql.gz

Backup remote ke laptop lokal tanpa login manual — via SSH tunnel:

ssh user@server.example.com "mysqldump -u USER -p'PASS' --single-transaction DB" | gzip > ~/Downloads/backup-remote-$(date +%F).sql.gz

Perintah ini menarik dump langsung ke mesin Anda. Kredensial DB tidak perlu exposed ke internet publik selain SSH. Rotasi 7–14 hari — hapus file lama agar disk tidak penuh (penyebab dump 0 KB).

Validasi Backup — Jangan Skip

Restore ke database staging, bukan production. Cek login admin, homepage, satu transaksi/form. Backup tanpa uji restore = harapan, bukan prosedur. Menurut kami, langkah ini yang paling sering di-skip pemula Indonesia — lalu panik saat disaster nyata.

Prosedur validasi minimal (15 menit, worth it):

1. Buat database staging kosong, import dump.
2. Point config staging (wp-config / .env) ke DB staging — jangan sentuh production config.
3. Login admin; buka 3 halaman kritis (homepage, checkout/form, dashboard).
4. Cek satu record transaksi/order acak bila e-commerce.
5. Catat checksum file (md5sum backup.sql.gz) di log backup — bukti integritas file.

Export Database MySQL — Jalur Internal

Export database mysql = mengeluarkan isi DB ke file (.sql, .sql.gz). Export db phpmyadmin bisa Quick (semua tabel) atau Custom (pilih tabel, structure/data only, DROP TABLE). Export partial cocok bila hanya migrasi konten — bukan full clone.

Langkah Custom export phpMyAdmin yang aman:

1. Pilih database di sidebar kiri.
2. Tab Export → Custom.
3. Centang tabel yang dibutuhkan (atau Select all untuk full).
4. Format SQL; centang Add DROP TABLE bila target DB kosong.
5. Centang gzipped bila total >20 MB.
6. Di bagian Data creation options, pilih utf8mb4 bila server mendukung.

Bedanya dengan backup: semua backup melibatkan export, tapi tidak setiap export disimpan dengan strategi retensi & offsite. Export sekali lalu hapus ≠ backup database.

Export partial berguna saat merge: ambil hanya wp_posts dan wp_postmeta dari staging, bukan seluruh schema. File lebih kecil, risiko overwrite tabel sensitif (users, options) lebih rendah.

Bila export lewat hosting panel (bukan phpMyAdmin), unduh file segera ke eksternal — link download panel sering expired 24 jam. Untuk migrasi antar provider, kombinasikan export SQL dengan arsip file via FTP/SFTP; set DNS baru mengikuti panduan DNS Record Cloudflare bila nameserver ikut pindah.

Import Database MySQL — Internal vs Eksternal

Definisi Import Internal

Import internal: file sudah di server (upload File Manager) → Import tab phpMyAdmin. Cocok DB <50–100 MB tergantung limit host.

Definisi Import Eksternal

Import eksternal: file dari laptop/hosting lama di-upload ke server baru. Skenario klasik migrasi hosting — sering berpasangan dengan ubah DNS; baca panduan DNS Record Cloudflare bila nameserver ikut pindah.

Import via phpMyAdmin (Tanpa SSH)

Tab Import → pilih file SQL. Limit upload_max_filesize dan max_execution_time sering 8–128 MB / 30–120 detik — sumber utama gagal import database phpmyadmin. Gejala: progress bar berhenti, halaman timeout, atau error #2006.

Workflow import tanpa terminal:

1. Buat database kosong dari cPanel → MySQL Databases.
2. Assign user dengan ALL PRIVILEGES.
3. Buka phpMyAdmin → pilih DB kosong → Import.
4. Centang Allow interruption bila ada (beberapa versi).
5. Setelah selesai, update file config CMS ke DB baru.

Bila gagal import database phpmyadmin di tengah: cek apakah DB target sudah berisi tabel (duplicate key). Truncate atau drop database, buat ulang, import lagi. Jangan import ke DB production yang masih live tanpa maintenance mode.

Import via CLI — Database Besar

# Import plain SQL
mysql -u USER -p DATABASE < backup.sql

# Import compressed
gunzip < backup.sql.gz | mysql -u USER -p DATABASE

# WordPress
wp db import backup.sql

Di Windows/Laragon/XAMPP path absolut masih valid. Laravel: import SQL dulu, lalu php artisan migrate --force hanya bila schema perlu sync — jangan asal migrate:fresh.

Restore Database WordPress — Langkah Praktis

Setelah import dump WordPress:

1. Pastikan wp-config.php menunjuk DB yang benar.
2. Bila domain berubah, update siteurl dan home di wp_options — atau pakai WP-CLI search-replace.
3. Flush permalink: Settings → Permalinks → Save (tanpa ubah apa pun).
4. Nonaktifkan plugin cache sementara; clear object cache bila Redis/Memcached aktif.
5. Login admin; cek Media Library — URL gambar kadang masih absolut ke domain lama.

Restore database mysql WordPress tanpa folder wp-content/uploads = konten ada, gambar 404. Backup database saja cukup untuk recovery teks dan setting — media butuh sync file terpisah.

Restore Laravel & Joomla — Catatan Singkat

Laravel: setelah import, jalankan php artisan config:cache hanya bila .env final sudah benar. Session driver database? Truncate sessions bila cookie stale. File storage/ tidak ikut dump SQL — backup terpisah.

Joomla: edit configuration.php — set public $live_site ke URL baru. Clear cache dari System → Clear Cache. Extension yang simpan path absolut di DB butuh search-replace manual atau tool migrasi Joomla.

Playbook Import Database Besar

Import database mysql big size (>500 MB) butuh playbook khusus:

Shared hosting Niagahoster, Dewaweb, atau sejenisnya sering tidak buka SSH default — minta akses sementara atau gunakan plugin migrasi berbayar bila CLI mustahil.

Import database mysql big size via split file (contoh Linux/macOS):

split -l 5000 backup.sql part_
for f in part_*; do mysql -u USER -p DATABASE < "$f"; done

Proses ini lambat tapi melewati limit upload phpMyAdmin. Pastikan urutan part tetap benar; jangan shuffle file.

Restore Database MySQL — Kapan Restore vs Import?

Import = memasukkan dump ke database (kosong atau existing). Restore = mengembalikan ke kondisi titik waktu backup setelah failure. Restore checklist:

1. Aktifkan maintenance mode.
2. Backup DB current — meski rusak, untuk forensik.
3. Drop/recreate DB atau overwrite import.
4. WordPress: update siteurl / home bila domain berubah.
5. Flush cache; uji login & form.

Setelah restore WordPress, error permission admin sering muncul — topik terpisah di panduan error WordPress pasca migrasi. Backup dan restore database harus satu paket dengan file wp-content bila plugin/theme versinya beda.

Merge Backup Database — Konsep, Use Case, dan Risiko

Merge database = menggabungkan sebagian atau seluruh data dari dump A ke DB B tanpa full replace. Jarang dibahas di tutorial Indonesia — padahal diminta saat staging sudah punya konten baru, production tetap live.

Kapan Perlu Merge Database?

• Partial merge staging → production (hanya tabel konten).
• Recovery: ambil wp_posts dari backup kemarin, sisanya tetap.
• Multisite advanced — hanya untuk yang paham ID collision.

Merge vs Full Replace

Teknik Merge Backup Database yang Aman (WordPress)

Backup both source & target. Import source ke DB staging. Export hanya tabel yang dibutuhkan. Jangan replace URL manual di SQL — pakai wp search-replace. Laravel: merge via seeder/script, bukan raw SQL kecuali Anda paham schema.

Workflow merge partial yang kami pakai untuk klien WordPress:

1. Backup production (file + DB) — titik rollback.
2. Import dump staging ke database staging_merge terpisah.
3. Identifikasi tabel target: konten saja (wp_posts, wp_postmeta, wp_terms, wp_term_relationships).
4. Export tabel tersebut dari staging_merge via phpMyAdmin Custom.
5. Import ke DB staging copy production — **bukan** production langsung.
6. Jalankan search-replace URL; uji checkout, form, login.
7. Bila OK, ulangi ke production di maintenance window.

ID collision? Post ID 500 di staging dan ID 500 di production beda artikel — merge raw menimpa salah satu. Solusi: remap ID via script atau export hanya post_type tertentu dengan offset ID (advanced).

Studi Kasus: Merge Database Gagal di Toko Online Tangerang

Klien kami — toko material lokal di Tangerang — punya staging WordPress + WooCommerce dengan 400 produk revisi. Production tetap jalan dengan 380 produk live. Tim internal import dump staging penuh ke production malam Minggu tanpa staging merge.

Hasilnya: order ID bentrok, 23 produk duplicate slug, checkout error 500. Akhirnya kami restore database mysql dari backup pre-merge (file .sql.gz 1,2 GB via CLI), lalu merge partial hanya tabel wp_posts + wp_postmeta di environment terpisah. Pelajaran: merge partial butuh map ID, bukan “import saja”.

WooCommerce dengan HPOS aktif, membership, atau subscription — jangan merge sendiri. DB >5 GB tanpa staging? Stop DIY.

Studi Kasus: Restore Database Pasca-Hack di Portal Berita Jakarta

Situs berita lokal di Jakarta kena inject malware via plugin nulled. Admin panik, langsung restore backup database internal seminggu lalu — tanpa cek apakah backup itu sudah terinfeksi.

Ternyata backup internal ikut menyimpan backdoor di wp_options (active_plugins dimanipulasi). Situs “pulih” tapi malware muncul lagi dalam 48 jam. Akhirnya tim isolasi server, restore dari dump eksternal 3 minggu sebelumnya (file di Google Drive admin), plus reinstall core WordPress dan scan wp-content.

Pelajaran: backup internal setelah breach bisa sudah tercemar. Simpan cadangan **pre-infection** offsite; setelah restore, rotate semua password DB dan admin, audit user dengan role administrator.

Risiko Kegagalan Backup, Export, Import — dan Solusinya

Matriks Risiko

php.ini dan MySQL Config

upload_max_filesize = 256M
post_max_size = 256M
max_execution_time = 300
memory_limit = 512M

; my.cnf
max_allowed_packet = 256M

Shared hosting: buka ticket — Anda tidak selalu punya akses edit langsung. Dokumentasi resmi MySQL backup: dev.mysql.com — mysqldump.

Decision Tree — Jalur Anda yang Mana?

Punya SSH? → mysqldump + mysql CLI + cron. Tidak punya SSH? → phpMyAdmin/plugin. DB >100 MB? → CLI atau split file. Platform WordPress? → WP-CLI + plugin. Laravel? → dump + .env. Joomla? → SQL + configuration.php + media.

Arsitektur WordPress headless pun tetap butuh backup database untuk CMS backend — meski front-end terpisah; baca analisis headless WordPress untuk konteks decoupled stack.

Decision Tree — Skenario Konkret Saat Melakukan Backup Database

Hosting Indonesia dengan panel custom kadang menyembunyikan opsi SSH — tanyakan explicit “akses SSH untuk mysqldump” sebelum commit paket tahunan untuk situs DB besar.

Situs WordPress dengan tema custom (wisata, portal berita, company profile) tetap memakai struktur tabel inti yang sama — prosedur backup database WordPress tidak berubah meski front-end kompleks; contoh proyek tema custom ada di halaman jasa buat tema WordPress untuk situs wisata.

Checklist Perawatan Backup Database Bulanan

WordPress: revisions, transients, spam comments membesarkan DB — bersihkan setelah backup verified. OPTIMIZE TABLE di InnoDB modern sering placebo; fokus ke hapus bloat, bukan ritual optimize mingguan.

Query audit revisions WordPress (jalankan di staging dulu):

SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';
DELETE FROM wp_posts WHERE post_type = 'revision' AND post_date < DATE_SUB(NOW(), INTERVAL 90 DAY);

Transients expired menumpuk di wp_options — plugin cleanup seperti WP-Optimize membantu, tapi **selalu** backup dulu. Satu DELETE salah scope bisa kosongkan opsi penting.

Untuk situs dengan traffic tinggi, pertimbangkan read replica atau managed database — topik di luar scope artikel ini, tapi backup tetap wajib meski infra sudah “enterprise”.

Tim yang mengelola banyak situs korporat kadang menyerahkan lapisan monitoring + backup otomatis ke partner teknis. Web developer CodeF sering diajak audit restore setelah klien pindah hosting — bukan karena mereka tidak bisa export, melainkan restore gagal validasi.

FAQ Backup Database Website

Backup database internal saja cukup tidak?
Tidak untuk skenario disaster. Internal cepat, namun server mati = backup ikut hilang. Duplikasi eksternal wajib.

Berapa ukuran database aman di-import via phpMyAdmin?
Di banyak host shared, batas aman di bawah 50–100 MB — tergantung limit host. Lebih besar → CLI atau split file.

Bisa import database WordPress ke Laravel?
Tidak langsung. Schema berbeda total. Anda perlu migrasi custom/ETL — bukan hanya import SQL mentah.

Bagaimana cara backup database WordPress tanpa SSH?
phpMyAdmin Export, cPanel backup, atau plugin UpdraftPlus/Duplicator.

Apa beda export dan backup database?
Export = aksi keluarkan data. Backup = strategi retensi + offsite + validasi restore.

Kenapa import database gagal di tengah jalan?
Timeout PHP, max_allowed_packet kecil, file terlalu besar, atau disk penuh. CLI sering menyelesaikan tiga masalah pertama.

Merge database WooCommerce aman dilakukan sendiri?
Jarang. Order ID dan HPOS rentan bentrok. Butuh staging dan map ID.

mysqldump vs plugin backup — mana lebih baik?
DB besar dan cron server → mysqldump. Shared hosting tanpa SSH → plugin + export manual berkala.

Seberapa sering harus backup database?
Situs aktif harian (otomatis) + backup eksternal mingguan verified. Situs brosur bulanan bisa lebih jarang — asal pre-update selalu backup.

Apakah backup plugin WordPress menggantikan mysqldump?
Untuk DB kecil-menengah di shared hosting, plugin cukup. DB >500 MB atau butuh cron server-level → mysqldump lebih andal dan tidak bergantung timeout browser.

File .sql.gz corrupt — bagaimana cek?
Jalankan gunzip -t backup.sql.gz di terminal. Bila error, dump gagal saat export — ulangi backup, cek disk space server.

Kapan memakai jasa maintenance website alih-alih DIY?
Bila merge riskan, DB >5 GB, tidak punya staging, atau restore sudah gagal dua kali. Untuk perawatan holistik (backup + update + monitoring), lihat jasa maintenance website — tanpa menggantikan kebutuhan memahami backup dasar di artikel ini.

Tiga takeaway teknis: (1) backup database baru sah setelah restore uji, (2) import besar hampir selalu butuh CLI, (3) merge hanya di staging. Butuh bantuan implementasi atau audit restore pasca migrasi, tim CodeF bisa bantu — termasuk situs company profile via jasa website company profile bila rebuild lebih masuk akal daripada merge.