# Modificare il database in un backup per rimuovere un tag chiave duplicata ed evitare fallimenti nel ripristino.
**URL:** https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039
**Category:** Self-hosting
**Created:** [27 Luglio 2023, 12:25pm UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039 "2023-07-27T12:25:26Z")
**Posts on this page:** 9
**Page:** 2
### Author:  [@Drew-ART](https://meta.discourse.org/u/Drew-ART)
#### Post date: [22 Agosto 2023, 8:01pm UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039/21 "2023-08-22T20:01:57Z")
```plaintext
andy@ubuntu-s-1vcpu-1gb-ams3-01:/var/discourse/shared/standalone/backups/default$ file public-happiness-2023-07-25-033857-v20220628031850.tar.gz
public-happiness-2023-07-25-033857-v20220628031850.tar.gz: gzip compressed data, was "public-happiness-2023-07-25-033857-v20220628031850.tar", last modified: Tue Aug 8 14:53:40 2023, max speed, from FAT filesystem (MS-DOS, OS/2, NT)
```
Il contenuto completo del file sembra a posto, anche se è difficile dirlo dato che si tratta di molte informazioni: [Hastebin](https://hastebin.com/share/xupiyenesu.bash)
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [22 Agosto 2023, 8:09pm UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039/22 "2023-08-22T20:09:30Z")
Penso che abbia a che fare con i percorsi dei file. Dai un’occhiata a
>
Hmm. Potrebbe non essere quello il problema. Per lo più non mi fido di `7zip` per creare un file `tar` compatibile, ma potrebbe essere irrazionale.
```plaintext
-h, --dereference
Segui i symlink; archivia e scarica i file a cui puntano.
```
> [@Drew-ART](#):
>
> La mia domanda qui sopra riguarda il motivo per cui lo strumento di ripristino del backup stava cercando e non trovando: /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz
La risposta potrebbe essere nel file sopra. In realtà, probabilmente si trova in un altro file nella stessa directory.
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [22 Agosto 2023, 9:11pm UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039/23 "2023-08-22T21:11:34Z")
Grazie: contenuti corretti, ma con nomi errati, credo. Da qui il problema.
Hai
```plaintext
-rwxrwxrwx 0/0 26927534 2023-08-08 14:37 public-happiness-2023-07-25-033857-v20220628031850/dump.sql.gz
```
ma l’originale e qualsiasi backup non modificato avrebbero
```plaintext
-rwxrwxrwx 0/0 26927534 2023-08-08 14:37 dump.sql.gz
```
Modifica: quindi devi gestire 7zip in modo leggermente diverso nella creazione di quel file tar.gz.
---
### Author:  [@Drew-ART](https://meta.discourse.org/u/Drew-ART)
#### Post date: [25 Agosto 2023, 4:31pm UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039/24 "2023-08-25T16:31:06Z")
Grazie per tutto il tuo aiuto. Ho decompresso i file, modificato nuovamente il tag duplicato e poi l’ho ricompresso con molta attenzione, prestando particolare attenzione al nome del file, e ci sono progressi!
Ora, durante il ripristino, vedo questo messaggio di errore, che sembra essere molto più comune:
```plaintext
[2023-08-25 15:25:21] CREATE INDEX
[2023-08-25 15:25:21] ERROR: could not create unique index "index_tags_on_lower_name"
[2023-08-25 15:25:21] DETAIL: Key (lower(name::text))=(socialmedia) is duplicated.
[2023-08-25 15:25:21] EXCEPTION: psql failed: DETAIL: Key (lower(name::text))=(socialmedia) is duplicated.
```
Suppongo che ciò significhi che ho modificato con successo il tag, ma ci sono ancora alcune occorrenze del tag nei post nel mio database. Il numero del tag\_id indica che dovrebbe esserci un tag chiamato socialmedia, ma invece sta trovando un tag chiamato socialmedia2, il che sta causando un conflitto.
[questo post](https://meta.discourse.org/t/cant-restore-due-to-corrupt-indexes-with-some-clues-on-how-to-deal-with-corrupt-indexes/137400/) e [quest’altro](https://meta.discourse.org/t/there-are-some-duplicated-tags-due-to-database-corruption-and-i-cant-merge/139506/) discutono di correzioni, ma poiché ho accesso al mio backup solo modificando direttamente il codice sulla mia macchina locale, non sono in grado di utilizzare gli strumenti mysql per aiutare a ripulirlo.
Fortunatamente nel mio database ho solo 38 istanze di ‘socialmedia’ (a differenza delle oltre 50.000 occorrenze di socialmedia). Supponendo che io abbia corretto correttamente la riga 395421 come ho mostrato nello screenshot, allora non riesco a capire quali delle rimanenti siano collegate al tag ‘socialmedia’ e quali al tag che ho modificato in ‘socialmedia2’.
Ecco un esempio di un post abbastanza breve che utilizza il tag socialmedia
```plaintext
9488 '/groups/communitybuilders':86 '/groups/socialmedia':84 '/groups/webdev':89 '1st':117 '2022':131 '6':125 'activ':61 'banner':113 'btw':143 'close':169 'comment':21 'communiti':47 'communitybuild':87 'concept':4A 'especi':28 'event':119 'excit':164 'feedback':8B 'final':166 'get':38,133 'github':94 'grow':6A,142 'hack':127 'hard':156 'help':96 'homepag':151 'host':124 'improv':11B 'join':71,106 'launch':41,118,126 'like':128 'link':110 'live':140,175 'lot':27 'love':1A,67 'marvelxi':152 'mean':25 'media':51 'member':62 'mention':93 'move':45 'much':15 'new':150 'one':72,107 'onto':53 'plan':121 'platform':7B,43,139 'pleas':5A 'project':137 'promot':97 're':33,36,56,161 'readi':39,172 'rhorho358':23 'right':63 'see':100,167 'site':176 'slight':76,177,179 'small':58 'smile':77,178,180 'social':50 'socialmedia':85 'stage':31 'suggest':10B 'sure':79 'take':17 'team':59,75,103 'thank':12 'think':147 'time':19 'use':108 'webdev':90 'websit':3A 'whether':80 'work':155 'would':66,82 Grazie mille per aver dedicato del tempo a commentare qui @R , significa molto, specialmente nel st... ha lavorato sodo e siamo tutti molto entusiasti di vederlo finalmente pronto sul sito live :slight_smile: :slight_smile: en_GB 4 f
```
Tuttavia, potrei essere sulla strada sbagliata, poiché all’inizio sembrano esserci più tag di quanti un utente possa utilizzare in un post. È anche possibile che ‘socialmedia’ non sia un tag utilizzato nel post sopra, anche se dovrebbe esserlo.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [26 Agosto 2023, 1:49am UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039/25 "2023-08-26T01:49:53Z")
Ripristinerei il database manualmente e proverei ad aggiungere gli indici e a correggere i problemi del database piuttosto che un file di testo, ma anche questo è difficile.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [26 Agosto 2023, 6:02am UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039/26 "2023-08-26T06:02:55Z")
> [@Drew-ART](#):
>
> Suppongo che ciò significhi che ho cambiato correttamente il tag, ma ci sono ancora alcune occorrenze del tag nei post nel mio database. Il numero tag\_id dice che dovrebbe esserci un tag chiamato socialmedia ma invece sta trovando un tag chiamato socialmedia2 che sta causando un conflitto.
1. Non credo che questa sia la conclusione immediata che puoi/dovresti trarre. Il problema dovrebbe essere semplice:
>
1. Inoltre, i post non vengono taggati, i topic sì.
_Prima di eliminare i duplicati, annota i loro ID perché dovrai eliminare anche le righe correlate dalla tabella topic\_tags_ (qualcosa che avresti potuto risolvere rapidamente se avessi eseguito tutta questa manutenzione online semplicemente riavviando il container invece di distruggere l’istanza!!).
>
---
### Author:  [@Drew-ART](https://meta.discourse.org/u/Drew-ART)
#### Post date: [30 Agosto 2023, 8:33am UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039/27 "2023-08-30T08:33:36Z")
Il nostro sito è tornato! Grazie a tutti per il vostro aiuto.
Sembra che avessi risolto giorni fa, ma sono stato negligente nel leggere il messaggio di errore. C’erano due tag duplicati, ‘socialmedia’ e ‘social-media’. Dopo aver corretto il primo, non ho notato che il messaggio di errore era cambiato, data la somiglianza tra i due tag duplicati.
Ecco i passaggi per correggere questi due errori:
**1. Trovare la tabella dei tag e il tag duplicato**
- Scarica il backup sul tuo sistema operativo. Questa guida è per Windows, ma il processo sarà più o meno lo stesso su Linux.
- Estrai tutte le cartelle zippate, che dovrebbero lasciarti un file dump.sql e una cartella uploads.
- Apri il file dump.sql con un editor di testo, io ho usato Visual Studio Code.
- Cerca “COPY public.tags” per individuare la tabella dei tag. Dovrebbe trovarsi verso il fondo e apparire così:
- Sfogliala manualmente o copia incolla la tua tabella dei tag in un documento separato dove puoi usare la funzione di ricerca per trovare il tuo tag duplicato.
- Salva il tuo file dump.sql corretto come dump.sql.
**2. L’ordine e i nomi dei file e delle cartelle devono essere perfetti nella ri-compressione.**
- Dopo l’estrazione dovresti avere un file dump.sql e una cartella uploads.
- Fai clic destro su dump.sql. seleziona 7zip e ‘aggiungi all’archivio’.
- Seleziona gzip come formato di archivio, mantenendo lo stesso nome del file.
- Seleziona il nuovo file dump.sql.gz e il file uploads, quindi fai clic destro \> 7zip \> aggiungi all’archivio \> formato archivio: tar. Assicurati che il nome del file sia esattamente lo stesso del backup originale, dovrebbe apparire qualcosa di simile a: ‘public-happiness-2023-07-25-033857-v20220628031850’.
- Seleziona il tuo nuovo file .tar \> 7zip \> aggiungi all’archivio \> formato archivio: gzip. Assicurati che il nome del file sia esattamente lo stesso del backup originale, dovrebbe apparire qualcosa di simile a: ‘public-happiness-2023-07-25-033857-v20220628031850’.
- Il tuo risultato finale dovrebbe essere un file .tar.gz con lo stesso nome del tuo backup originale.
- Carica nell’area admin e ripristina il tuo backup.
---
### Author:  [@Drew-ART](https://meta.discourse.org/u/Drew-ART)
#### Post date: [30 Agosto 2023, 8:39am UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039/28 "2023-08-30T08:39:40Z")
C’è un altro posto in cui il tag è/potrebbe essere ripetuto ed è la tabella dei dati di ricerca:
> COPY public.tag\_search\_data (tag\_id, search\_data, raw\_data, locale, version) FROM stdin;
Non sono sicuro se anche questo debba essere corretto o meno.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [30 Agosto 2023, 10:21am UTC](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039/29 "2023-08-30T10:21:23Z")
Sono così felice che tu l’abbia finalmente sistemato!
[Pagina precedente](https://meta.discourse.org/t/modifying-the-database-inside-of-a-backup-to-remove-a-duplicate-key-tag-so-that-it-doesnt-fail-when-restoring/273039.md?page=1)