Tanya tentang proses migrasi directadmin

[Mas Alpii]

halo rekan2, saya sebenarnya cukup tertarik dengan directadmin. tetapi sampai sekarang belum cukup berani pakai untuk kebutuhan produksi shared hosting.
hal ini karena masih ada fitur yang menurut saya kurang efektif yaitu proses migrasi antar server yang dimana proses itu dilakukan secara manual hxxs://docs.directadmin.com/directadmin/backup-restore-migration/migrations.html
proses ini akan cukup merepotkan ketika server mempunyai ratusan akun, dengan data yang bergiga-giga, sekenceng apapun servermu proses backup itu saya yakin tidak akan selesai dalam 1 atau 2 jam. belum lagi proses scp file backup ke server baru yang harus memakan waktu lagi. ini tentu menurut saya kurang efisien.

untuk teman2 yang sudah menggunakan directadmin, metode apa yang digunakan untuk melakukan migrasi data antar sever pada directadmin ?
apakah ada tips and trick yang lebih mudah untuk melakukan migrasi antar server ?

note: yang saya infokan disini adalah migrasi full all akun/domain dari server A ke B. bukan untuk individual domain.
btw, hindari jawaban "bisa di restore dari sistem disasesternya jetbackup"

 

[syao]

ini migrasi nya dari directadmin ke directadmin lagi? Jika iya, memang saat ini sistem directadmin untuk migrasi antar server bisa dinilai sangat tidak efisien dibanding cpanel.

dan metode migrasi nya masih menggunakan apa yang disarankan directadmin yaitu backup/restore, tapi untuk backup destination nya bisa di set FTP ke server tujuan migrasi, supaya tidak buang waktu transfer file lagi dari server asal ke tujuan saat proses backup sudah selesai. Pernah coba backup/restore tanpa homedir, tapi ada masalah di ownership di server tujuan (mungkin karena salah setting rsync atau hal lainnya), jadi tetap balik lagi menggunakan backup/restore yang disarankan directadmin.

pengalaman terakhir migrasi DA server sekitar 800GB, makan waktu 12 jam (backup/restore) dengan 10Gbps interface dan SSD RAID10 ditiap server DA nya

 

[Mas Alpii]

ini migrasi nya dari directadmin ke directadmin lagi?

betul dari da ke da mas

tapi untuk backup destination nya bisa di set FTP ke server tujuan migrasi, supaya tidak buang waktu transfer file lagi dari server asal ke tujuan saat proses backup sudah selesai.

ini akan bekerja maksimal ketika koneksi antar server lancar, kalau tidak stabil maka prosesnya juga akan menambah lebih lambat.
yang jadi masalah ketika kita sedang melakukan proses backup kemudian memindahkan data dari server lama ke server baru begitu juga dengan proses restornya user masih memungkinkan melakukan update data pada web mereka yang nantinya ketika proses restore data menjadi tidak syncron dengan data yang mereka update ketika kita masih dalam proses backup. ini krusial menurut saya.

 

[natanetwork]

kalo restore nya bisa point ke direktory tertentu..lalu ada list username nya bisa di centang mana2 yg mau di restore..
kalo backup nya bisa ditempatkan di 1 folder untuk semua akun..

 

[Mas Alpii]

kalo restore nya bisa point ke direktory tertentu..lalu ada list username nya bisa di centang mana2 yg mau di restore..
kalo backup nya bisa ditempatkan di 1 folder untuk semua akun..

paham mas, masalahnya bukan ini
tapi adalah proses backup manual untuk semua akun, yang nanti harus dilakukan scp manual ke server tujuan
proses ini yang memakan waktu lama

 

[natanetwork]

scp nya kan 1x aja untuk 1 folder itu.. tidak one by one scp..

atau kalo mau langsung FTP jg bisa

 

[Mas Alpii]

scp nya kan 1x aja untuk 1 folder itu.. tidak one by one scp..

atau kalo mau langsung FTP jg bisa

iya sudah paham mas, coba di teliti lagi apa yang saya tulis.

 

[pluto01]

betul dari da ke da mas

ini akan bekerja maksimal ketika koneksi antar server lancar, kalau tidak stabil maka prosesnya juga akan menambah lebih lambat.
yang jadi masalah ketika kita sedang melakukan proses backup kemudian memindahkan data dari server lama ke server baru begitu juga dengan proses restornya user masih memungkinkan melakukan update data pada web mereka yang nantinya ketika proses restore data menjadi tidak syncron dengan data yang mereka update ketika kita masih dalam proses backup. ini krusial menurut saya.

Proses backup dan restore gmnpun polanya tetap butuh waktu, untuk user2 yg krusial perlu komunikasi
Untuk pola agar sedikit mempersingkat (tapi saya tidak paham apakah ini berjalan di DA atau tidak)
1. Kondisi masih aktif di server lama
2. Proses backup data yang ada
3. Restore ke server baru
4. Buat 2 NS, 1 ke server lama dan 1 lagi ke server baru
5. Jika sampai tahap-4 masih aman, lakukan sync untuk memastikan jika ada yang melakukan perubahan data terbaru bisa terbawa ke server baru, karena perubahannya tidak besar tentu tidak lama
6. Offkan NS ke server lama dan cukup NS ke server baru saja aktif. Karena sebelumnya sudah aktif tentu proses propagasinya atau refresh dns untuk resolv ke server baru tidak lama

Jadi waktu yang lama di tahap-2 dan 3 ini tidak terasa karena masih aktif
Dengan catatan kedua server aktif

Namun jika karena satu hal dan memerlukan salah satu off (dalam arti tidak bisa diakses public) maka mau tidak mau emang perlu waktu tergantung seberapa besar data


CMIIW

 

[Mas Alpii]

Proses backup dan restore gmnpun polanya tetap butuh waktu, untuk user2 yg krusial perlu komunikasi
Untuk pola agar sedikit mempersingkat (tapi saya tidak paham apakah ini berjalan di DA atau tidak)
1. Kondisi masih aktif di server lama
2. Proses backup data yang ada
3. Restore ke server baru
4. Buat 2 NS, 1 ke server lama dan 1 lagi ke server baru
5. Jika sampai tahap-4 masih aman, lakukan sync untuk memastikan jika ada yang melakukan perubahan data terbaru bisa terbawa ke server baru, karena perubahannya tidak besar tentu tidak lama
6. Offkan NS ke server lama dan cukup NS ke server baru saja aktif. Karena sebelumnya sudah aktif tentu proses propagasinya atau refresh dns untuk resolv ke server baru tidak lama

Jadi waktu yang lama di tahap-2 dan 3 ini tidak terasa karena masih aktif
Dengan catatan kedua server aktif

Namun jika karena satu hal dan memerlukan salah satu off (dalam arti tidak bisa diakses public) maka mau tidak mau emang perlu waktu tergantung seberapa besar data


CMIIW

terima kasih jawabannya pak, cukup rinci sekali.
namun mohon maaf sebelumnya bisa di pahami dulu step by step proses migrasi DA pada link yang telah saya lampirkan diatas.

1. kondisi kedua server tentu dalam keadaan aktif

2. Proses backup tertulis oleh DA
" (On the old server, for each Admin/Reseller, log in as them, and go to their Reseller Panel -> Manage User Backups. Select all accounts, and make a local backup of those accounts. We recommend doing a local backup and then transferring the files over to the new server manually. )"
yang berarti bahwa proses backup dilakukan secara manual, yang akan disimpan pada lokal server untuk kebutuhan scp file. jadi jika ada ratusan akun/domain dengan total disk yang bergiga-giga bahkan mungkin bertera-tera proses backup akan memakan waktu cukup lama.

3. Proses ketiga yaitu scp file, ketika langkah ke 2 sudah selesai maka kita masih harus melakukan scp file backup ke server baru, yang tentu ini akan memakan waktu lagi untuk menunggu proses scp file selesai di server baru.

4. Restor data, setelah proses no 3 selesai maka kita masih harus melakukan proses restore akun dimana ini tentu juga akan memakan waktu lagi.

5. Proses restore selesai, data tidak syncron karena sudah termakan waktu di langkah 2,3 dan 4.

 

[pluto01]

5. Proses restore selesai, data tidak syncron karena sudah termakan waktu di langkah 2,3 dan 4.

Coba test simulasi 1 account dulu, migrasi satu data dari server lama ke server baru sesuai arahan DA, tunggu sekitaran beberapa hari atau 1 minggu sampai ada perubahan data di server lama.
Kemudian coba sinkronkan data server baru dengan server lama dengan sumber server lama
Kemudian coba check di sisi server baru ada issue terkait permission and writable folder/content di account tersebut tidak setelah sinkron?
Jika tidak ada maka bisa berjalan