Siti web
Ripristino a un momento specifico nel tempo
Point-in-time recovery lets you rebuild your database as it was at a chosen minute, rather than only at the moment yesterday's backup ran. This guide covers what it does and does not cover, how to…
Recupero Point-in-Time
Il recupero point-in-time ti permette di ricostruire il database come era in un minuto specifico a tua scelta, anziché solo nel momento in cui è stato eseguito il backup di ieri. Questa guida spiega cosa copre e cosa non copre, come abilitarlo, come richiedere un ripristino e esattamente cosa tocca un ripristino.
A Cosa Serve
Un backup giornaliero ti fornisce un punto di ripristino al giorno. Va bene per la maggior parte dei disastri ed è inutile per quello specifico in cui un'importazione errata, un plugin difettoso o una modifica in massa errata è stata eseguita alle 14:15 e te ne sei accorto alle 16:00. Il ripristino del backup di ieri comporterebbe la perdita di tutto il lavoro reale della mattinata insieme all'errore.
Il recupero point-in-time chiude quella lacuna. Con esso abilitato, il log delle modifiche del database viene inviato continuamente all'archiviazione esterna, quindi un ripristino può essere riprodotto fino a qualsiasi minuto all'interno della finestra di conservazione.
Il recupero point-in-time copre SOLO il DATABASE. Non copre i tuoi file: nessun caricamento, nessun codice tema o plugin, nessun file di configurazione su disco. Se qualcuno ha eliminato una cartella di immagini, PITR non la riporterà indietro. Per i file hai bisogno di un backup dei file. Vedi Esecuzione di un Backup e Ripristino da un Backup.
Dove si Trova in KPanel
- Accedi a KPanel.
- Fai clic su Websites nella barra laterale sinistra, quindi fai clic sul sito.
- Nella striscia di schede del sito, apri Backups, quindi Point-in-time recovery.
L'indirizzo diretto è /websites/<site-id>/pitr.
Idoneità
Il recupero point-in-time richiede che due cose siano vere.
Il tuo piano deve includerlo. È disponibile sulle famiglie di piani WordPress.
Il sito deve essere un sito WordPress o WooCommerce, perché il meccanismo si basa su un database gestito.
Se uno dei due non è soddisfatto, la pagina lo dice chiaramente: il recupero point-in-time è disponibile solo per siti WordPress e WooCommerce con database gestiti. Non c'è nulla da configurare in quel caso.
Abilitazione
La scheda PITR status mostra lo stato attuale con un badge di stato, il backend in uso, quando è stato inviato l'ultimo log delle modifiche e la finestra di conservazione in giorni.
Fai clic su Enable PITR per attivarlo. La conservazione è di 30 giorni.
L'abilitazione non cambia nulla sui tuoi dati. Avvia un processo di spedizione continua che viene eseguito insieme ai tuoi backup giornalieri normali; non li sostituisce.
Non ci sono punti di ripristino immediatamente dopo l'abilitazione. La spedizione deve essere eseguita almeno una volta prima che qualcosa possa essere riprodotto, e la prima spedizione avviene entro circa cinque minuti. Fino ad allora la pagina ti dice che non ci sono ancora punti di ripristino.
Lettura della Finestra di Ripristino
Una volta che la spedizione è in esecuzione, la scheda Available restore window indica i momenti più primi e più tardivi a cui puoi ripristinare e quanti file di log delle modifiche vengono conservati per coprirla.
Leggi questo prima di averne bisogno, non durante un incidente. Se la finestra inizia più tardi del previsto, la spedizione è stata interrotta in un certo punto e la copertura più vecchia è scaduta.
Richiesta di un Ripristino
- Apri la scheda Point-in-time recovery.
- Conferma che la finestra di ripristino copra il momento desiderato.
- In Restore to timestamp, scegli la data e l'ora. Scegli un momento PRIMA del danno, non dopo.
- Fai clic su Request restore to staging DB.
La richiesta viene convalidata immediatamente. Se il timestamp rientra al di fuori della finestra disponibile, ti viene comunicata la finestra esatta anziché essere lasciato indovinare.
Cosa Fa Effettivamente un Ripristino
Questa è la parte in cui essere precisi, perché è l'opposto di quello che la maggior parte delle persone si aspetta.
Un ripristino point-in-time non tocca il tuo database live. Esegue il ripristino in un database di staging separato, che viene creato per lo scopo e denominato in base al tuo dominio e alla data di destinazione. Il tuo sito live continua a funzionare sul suo database durante tutto il processo, senza modifiche.
Niente viene sovrascritto, niente viene eliminato e nessun dato viene perso richiedendo un ripristino. È intenzionale: l'intero scopo di uno strumento di recupero dati è che utilizzarlo non possa peggiorare la situazione.
Quello che ottenuti è un database che puoi ispezionare. Puoi confrontarlo con quello live, estrarre le righe danneggiate o decidere che lo snapshot intero è la versione che desideri. Promuovere un ripristino di staging sul tuo database live è un passaggio separato e deliberato che il nostro team esegue con te, non qualcosa che un pulsante fa alle spalle.
Il passaggio a un database ripristinato SCARTA tutto ciò che è stato scritto nel database live dal punto di ripristino. Gli ordini effettuati, i commenti lasciati e i contenuti modificati dopo quel timestamp esistono solo nel database live. Prima di qualsiasi passaggio, decidi cosa deve essere trasportato in avanti e comunicalo. Questo è il motivo per cui il ripristino atterrà prima nello staging.
Monitoraggio della Richiesta
Ogni richiesta appare nella tabella Restore requests:
| Colonna | Cosa mostra |
|---|---|
| Requested | Quando l'hai richiesto |
| Target | Il timestamp che hai chiesto di ripristinare |
| Status | Dove la richiesta è arrivata |
| Staging DB | Il nome del database su cui viene eseguito il ripristino |
Mentre un ripristino è in esecuzione, lo stato mostra lo stage attuale e, una volta iniziata la riproduzione, quanti file di log delle modifiche sono stati applicati sul totale. Una richiesta non riuscita mostra l'errore sottostante.
Un solo ripristino può essere in corso per sito alla volta. Richiedere un secondo mentre uno è in esecuzione restituisce un conflitto piuttosto che l'accodamento, quindi un secondo tentativo non può corrompere il primo.
Il nostro team di ingegneria completa il ripristino di staging e ti invia un'email quando il database di staging è pronto. Riceverai anche un'email di conferma quando la richiesta viene ricevuta, con il timestamp di destinazione e il nome del database di staging.
Scelta del Timestamp Corretto
Individua quando il danno ha avuto inizio, non quando lo hai notato. Questi sono solitamente ore di differenza. Controlla il tuo log di attività, i timestamp degli ordini o l'ultima modifica di contenuto di cui sei sicuro.
Punta un paio di minuti prima. Un punto di ripristino poco prima dell'evento negativo ti costa un paio di minuti di scritture legittime. Uno poco dopo ripristina il danno insieme a tutto il resto.
Annota cosa è successo dopo il punto di ripristino. Ordini, iscrizioni, commenti, invii di moduli. Quell'elenco è quello che dovrai trasportare in avanti manualmente se decidi di passare.
Risoluzione dei Problemi
La pagina dice che PITR è disponibile solo per WordPress e WooCommerce. O il sito non è di uno di questi tipi, oppure il tuo piano non include la funzione.
Nessun punto di ripristino ancora. La spedizione deve essere eseguita almeno una volta dopo l'abilitazione. La prima spedizione avviene entro circa cinque minuti.
Il mio target è al di fuori della finestra disponibile. La conservazione è di 30 giorni e la finestra può essere più breve se la spedizione è stata interrotta. Il messaggio di errore indica i confini esatti. Se il momento di cui hai bisogno è scaduto, ricadere su un backup giornaliero: vedi Ripristino da un Backup.
Un ripristino è già in corso. Aspetta che finisca. La tabella mostra lo stage e lo stato di avanzamento.
Lo stato mostra un banner riguardante la spedizione. La tua richiesta è registrata e il messaggio spiega lo stato attuale. Niente viene perso.
Ho bisogno dei file, non del database. PITR non può aiutare. Usa un backup di file e nota che un backup completato può essere sfogliato file per file anziché ripristinato nel complesso.
Pagine Correlate
- Esecuzione di un Backup per i backup giornalieri di file e database che vengono eseguiti insieme a questo.
- Ripristino da un Backup per il percorso di ripristino dell'intero sito.
- Staging Environments per testare le modifiche prima che raggiungano la produzione.
- Site Security se la perdita di dati è stata causata da un compromesso piuttosto che da un errore.
Se sei nel mezzo di un incidente e non sei sicuro di quale strumento hai bisogno, contattaci da Support in KPanel o invia un'email a support@kapsulehost.com con il nome del sito e l'ora in cui il problema è iniziato.