Il backup dei dati è diminuito improvvisamente, il ripristino dei dati diminuiti è anomalo, il sito Web non può interagire normalmente, per fortuna il bucket di storage Amazon S3 può trovare dati storici, altrimenti la perdita sarebbe incommensurabile
Ci sono state modifiche alle impostazioni in quel lasso di tempo che potrebbero aver influito sull’inclusione dei caricamenti nei tuoi backup?
È stato eseguito un aggiornamento, è stato utilizzato un tema, è stato aggiunto un plugin personalizzato al tema (css personalizzato), gli utenti possono scegliere di disattivare la palette di colori, sono stati utilizzati data.yml, web_only.yml, dopo aver ripristinato i dati con 262 Mbyte, ora il backup è di soli 154 Mbyte, si stima che questi dati di backup siano ancora problematici
A quel punto sei passato a una configurazione a due container, o la stavi sempre usando?
Lo uso sempre, quali potrebbero essere le ragioni?
Ho provato a ripristinare il mio ultimo backup un paio di giorni fa e l’upload sul mio pannello è stato rifiutato. Per un attimo ho pensato che il mio backup fosse perso, così ho provato un altro caricamento su FTP e indovina un po’? Ripristinato! Ma è successo la stessa cosa e vorrei sapere il motivo.
Temo di avere più familiarità con l’installazione standard e non sono sicuro se la configurazione a due container abbia delle particolarità che potrebbero essere rilevanti qui.
Lascerò questo a Installation e vedremo se riusciamo a ottenere qualche occhio più esperto.
(@pfaffman
)
In precedenza ho utilizzato un’installazione standard, ma l’installazione standard presenta un problema: ogni volta che modifico app.yml, il mio sito web non è accessibile. Se utilizzo data.yml o web_only.yml, posso apportare modifiche a web_only.yml senza influire sull’accessibilità del sito web. L’installazione standard ha una funzionalità simile? Come si usa specificamente?
No. L’unica differenza è che una ricostruzione ricostruisce solo le parti rails e nginx. Il database e redis rimangono gli stessi. Quelli cambiano raramente, quindi non hanno bisogno di essere ricostruiti. Funziona esattamente allo stesso modo. Lo capisci benissimo. (L’unica complicazione è quando c’è un aggiornamento di postgres o redis, che avviene all’incirca una volta all’anno, anche se ci sono stati alcuni aggiornamenti del database dovuti ai requisiti del plugin AI. Quindi, se non stessi usando il plugin AI, andresti benissimo, ma se lo stessi usando, otterresti errori di database confusi se non ricostruissi anche il container dei dati.)
La mia ipotesi è che abbiano spostato gli asset su s3 e quindi gli upload locali non siano inclusi. Questo è coerente con quanto hanno detto, ovvero che sono stati in grado di ripristinare le cose da s3. Oppure potrebbero aver eliminato alcuni post che avevano degli upload, quindi quegli upload non sono stati inclusi nei backup successivi.
Inoltre, è sembrato un po’ come se avessero eseguito un ripristino e non avessero aspettato che finisse completamente.
Ho utilizzato un plug-in AI. A cosa devo prestare attenzione affinché i dati di backup possano essere utilizzati? Come dovremmo affrontare questo tipo di problema
Significa che finché data.yml non viene ricostruito non ci sono problemi, o è necessario utilizzare app.yml, o questo tipo di problema esiste sia nel piano web_only di data.yml che nel piano app.yml
Il problema è che quando ho eseguito il backup, il container creato da data.yml non era supportato e il database è stato aggiornato. Se il rebuild di data.yml viene aggiornato, non ci saranno problemi anche se si esegue un importante aggiornamento del database, e quindi non ci saranno problemi con il backup e il ripristino. Come posso sapere che il vostro database è stato modificato in modo significativo?
Il problema è che quando ho eseguito il backup, il container creato da data.yml non era supportato e il database è stato aggiornato. Se il rebuild di data.yml viene aggiornato, non ci saranno problemi anche se si esegue un importante aggiornamento del database, e quindi non ci saranno problemi con il backup e il ripristino. Come posso sapere che il vostro database è stato modificato in modo significativo?
@sober, come nota di processo, è molto più facile per chi legge/vuole aiutare se includi una traduzione in inglese nei tuoi post. Potresti modificarne una. ![]()
Ora capisco che il problema è stato un grande aggiornamento del database che ha causato problemi di backup.
Quando Discourse viene aggiornato, come posso assicurarmi che la versione aggiornata sia in versione beta invece che in versione di sviluppo? Dopo che l’ultimo backup è andato storto, devo preoccuparmi delle operazioni di aggiornamento e ripristino del backup
Cosa? Beh, aspetterò una conferma perché non so se si romperà qualcosa qui.
Voglio aggiornare solo beta2, non beta2-dev, perché temo che dev sia instabile e il recente backup dei dati non possa essere ripristinato normalmente, causando quasi una perdita di dati. Ho utilizzato il backup precedente per il backup, ma i dati sono comunque andati persi per un certo periodo di tempo.
Non lo sono, è solo una modifica recente al sistema di versioning. Tecnicamente, non dovresti nemmeno vedere le etichette -dev.


