KRIPTO TANPA KYCSewa GPU · 3, 7, atau 30 hari
Capordia
Bahasa: Bahasa Indonesia
Menu
Kelangsungan / Pemulihan

Cadangan harus memungkinkan pekerjaan dilanjutkan.

Keberadaan arsip dan kecocokan checksum-nya tidak membuktikan bahwa sebuah tim dapat melanjutkan pekerjaannya. Uji pemulihan harus memulihkan status yang dapat dipahami, membuka file yang diperlukan, dan menjalankan operasi yang berguna dalam lingkup terisolasi. Siapkan uji ini selagi orang-orang yang memahami proyek masih tersedia.

01

Menentukan status yang harus dipulihkan sebelum memilih file

Mulailah dengan satu kalimat yang dapat diverifikasi: melanjutkan tugas yang belum selesai, meninjau ulang hasil yang telah diterima, atau melanjutkan pelatihan dari status yang tersimpan. Tujuan-tujuan ini tidak memerlukan paket yang sama. Sebutkan versi aplikasi, kumpulan input, parameter, dan titik acuan waktu. Tanggal file yang baru tidak dengan sendirinya menunjukkan bahwa semua komponen mewakili status pekerjaan yang sama.

Untuk pelatihan PyTorch, dokumentasi membedakan parameter model dan checkpoint pemulihan yang mencakup antara lain status optimizer. Tentukan elemen yang diperlukan untuk protokol Anda sendiri: kemajuan, penjadwal bila ada, data, dan status aplikasi lainnya. Ekspor yang hanya ditujukan untuk inferensi bisa jadi valid untuk keperluan itu namun tidak memadai untuk melanjutkan pelatihan pada titik yang sama.

02

Membuat uji tidak bergantung pada direktori kerja

Siapkan tujuan terpisah, dengan ruang dan izin yang diperlukan. Identifikasi dengan jelas cadangan yang dipilih dan lindungi salinan referensinya. Uji tidak boleh menimpa pekerjaan yang sedang berjalan atau mempublikasikan hasilnya menggantikan keluaran yang telah diterima. Nonaktifkan atau alihkan tindakan eksternal aplikasi: pengiriman notifikasi, penulisan ke folder bersama, atau peluncuran kampanye tambahan.

Gunakan fungsi pemulihan alat Anda dalam lingkup ini. Restic misalnya memungkinkan pemilihan tujuan dengan --target dan pratinjau pemulihan dengan --dry-run. Dokumentasinya memperingatkan bahwa pemulihan di tempat dapat meninggalkan status parsial jika terhenti. Kemungkinan-kemungkinan ini menggambarkan metodenya; ini tidak berarti bahwa Restic atau cadangan terkelola disertakan dengan sewa Capordia.

03

Memeriksa salinan, status, dan penggunaan secara berurutan

Periksa terlebih dahulu bahwa paket sesuai dengan inventaris yang diharapkan dan file-file tidak berubah. Lanjutkan ke pembukaan yang sebenarnya: izin, jalur relatif, dependensi, pembacaan data, dan pemuatan status. Sebuah paket dapat lulus pemeriksaan integritasnya namun melewatkan file yang tidak pernah tercatat dalam inventaris. Pemeriksaan fungsional menjawab pertanyaan kedua ini.

Terakhir, jalankan operasi terbatas dalam proses baru, tanpa akses implisit ke direktori asal. Catat apa yang dibaca, apa yang dihasilkan, dan apa yang mengizinkan penerimaannya. Untuk pemulihan batch, periksa bahwa operasi tersebut tidak mempublikasikan ulang tugas yang sudah divalidasi. Uji pada beberapa input hanya membuktikan lingkup tersebut; ini tidak menjamin seluruh kampanye maupun durasi lengkapnya.

Tiga tingkat pemeriksaan yang saling melengkapi
TingkatPertanyaanElemen yang harus disimpan
IntegritasApakah paket yang diterima sesuai dengan paket yang direncanakan?Inventaris dan hasil pemeriksaan
Status pulihApakah file dan dependensi memungkinkan pemuatan?Versi, jalur, dan selisih yang tercatat
PenggunaanApakah operasi representatif memberikan hasil yang diharapkan?Input uji, output, dan keputusan
04

Contoh terselesaikan: arsip utuh yang tidak dapat dipulihkan

Kasus sepenuhnya fiktif: sebuah kampanye mencakup 240 berkas. Pada titik yang tersimpan, 180 diterima dan 60 masih harus diproses. Tim memulihkan arsip di ruang terpisah. Semua file yang terdaftar lolos pemeriksaan integritas, tetapi aplikasi tidak menemukan tabel pemetaan yang selama ini dimuat dari komputer seorang kolega. Restorasi ditolak: keadaan tidak dapat dilanjutkan secara mandiri.

Tim menambahkan versi persis tabel tersebut ke dalam paket dan mendokumentasikan jalurnya. Mereka mengulang restorasi ke tujuan baru, lalu memeriksa register: 180 + 60 = 240 pengenal, tanpa duplikat. Pada sepuluh berkas uji di antara enam puluh sisanya, pemrosesan menghasilkan dua puluh file yang diharapkan, yaitu dua per berkas. Isinya diterima sesuai kriteria yang ditetapkan. Sepuluh uji ini tetap terpisah dari hasil produksi; register awal tidak dimajukan oleh latihan tersebut.

05

Mengukur durasi lengkap dan mengetahui apa yang dibuktikannya

Catat waktu dari awal persiapan yang diperlukan hingga hasil yang diterima, dengan membedakan waktu tunggu, restorasi, konfigurasi dan pemeriksaan. Dalam contoh fiktif kami, tahapan ini masing-masing memerlukan 15, 75, 20 dan 25 menit: totalnya mencapai 135 menit, yaitu 2 jam 15 menit. Untuk jendela internal tiga jam, sisa cadangan bernilai 180 − 135 = 45 menit. Perhitungan ini tidak menggambarkan kinerja layanan apa pun.

Catat kondisi yang membuat pengukuran ini dapat digunakan kembali: ukuran paket, tujuan, versi, ketersediaan orang dan cakupan pemeriksaan. Usia cadangan menjawab pertanyaan lain: pekerjaan lanjutan apa yang mungkin perlu diulang? Restorasi cepat dari keadaan yang terlalu lama bisa tetap tidak dapat diterima. Tetapkan kedua kriteria bersama penanggung jawab proyek, tanpa mencampuradukkannya.

Waktu fiktif untuk uji yang dijelaskan
TahapWaktu
Menyiapkan tujuan15 menit
Memulihkan paket75 menit
Mengonfigurasi aplikasi20 menit
Menerima hasil uji25 menit
Total / cadangan pada 3 jam135 menit / 45 menit
06

Menyelesaikan latihan dan menyimpan langkah berikutnya yang jelas

Laporan cukup satu halaman: cadangan yang dipilih, tujuan, lingkungan uji, selisih, hasil yang diterima dan batasannya. Jika ada elemen yang kurang, tetapkan perbaikannya lalu ulangi pemeriksaan terkait. Jangan mengganti kegagalan dengan frasa samar seperti "arsip tersedia". Setelah latihan, identifikasi keluaran uji dan hapus sesuai prosedur Anda, tanpa menyentuh salinan yang disimpan untuk pelestarian.

Ulangi uji ketika format cadangan, perangkat lunak atau dependensi penting berubah, dan sebelum tenggat yang akan menyulitkan pemulihan. Iramanya bergantung pada proyek; itu bukan komitmen otomatis dari penyewaan. Pada periode 3, 7 atau 30 hari, sediakan waktu untuk memverifikasi pemulihan dan menyampaikan hasilnya kepada orang yang akan melanjutkan.

Pertanyaan untuk memutuskan

Apakah checksum yang benar cukup untuk menerima cadangan?

Itu memverifikasi kesesuaian file terkait, bukan kelengkapan proyek atau kemampuannya untuk memulai ulang. Tambahkan pemuatan di ruang terpisah dan operasi yang representatif. Laporan menjelaskan cakupan masing-masing pemeriksaan tersebut.

Apakah seluruh produksi harus direproduksi untuk setiap uji?

Tidak harus. Pilih cakupan yang mencakup dependensi dan kriteria penting, lalu sebutkan batasannya. Uji kecil berguna untuk mendeteksi file yang hilang; itu tidak mengukur kemampuan memulihkan volume yang jauh lebih besar.

Apa yang harus dilakukan jika uji berhasil hanya dengan direktori lama tetap dapat diakses?

Cari dependensi tersirat: konfigurasi, data, pustaka atau jalur eksternal. Tambahkan ke paket atau dokumentasikan cara menemukannya, lalu ulangi tanpa jalan pintas tersebut. Selama kebutuhan ini belum diketahui, pemulihan tetap bergantung pada lingkungan asal.

LANJUTKAN PROSESLihat konfigurasiLihat pertanyaan umum