Supporto feddit.it e accoglienza Redditors

463 readers

3 users here now

Comunità di supporto agli utenti e ai moderatori

NB: abbiamo attivato su questa comunità un centro di accoglienza, smistamento e primo soccorso per i migranti di Reddit! 😁

Lemmy, funzionalità e integrazione con altre piattaforme

founded 2 years ago

MODERATORS

[email protected]

Che rischio c'è che tutto quello che scriviamo qui su feddit scompaia? (feddit.it)

submitted 2 years ago by [email protected] to c/[email protected]

30 comments fedilink hide all child comments

Scusate la domanda da newbie.

Vengo da reddit, sto provando a guardarmi intorno, sto scoprendo una comunità viva e molto attiva, mi piace un bel po'!

C'è una questione che ho letto in un thread altrove che mi angoscia un pochino, devo ammetterlo, e quindi ho pensato di farla qui pubblicamente, in modo che (spero) qualcuna possa tranquillizzare me ed eventuali altri interessati.

Se ad un certo punto nel futuro (speriamo mai) succede qualcosa che costringe a "chiudere il server" su cui risiedono questi messaggi, perdiamo tutto o ci sono dei meccanismi di passaggio ad altro server / istanza percorribili?

Non sto pensando a casi di azioni malevole, ma piuttosto ad imprevisti (l'informatica ne è piena) o a cambi di obiettivi di chi cura il back end, o a forza maggiore (che ne so, un imprevisto giudiziario che mette davanti alla scelta chiudo tutto / rischio conseguenze penali).

Nel caso di reddit mi è chiaro: se la società fallisce, o decide di fare pulizia, si perde tutto, fine. Qui come funziona?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 2 points 2 years ago (1 children)

Che ne penseresti d'inviare una copia dei backup - magari sezionati in mesi o trimestri - ad archive, come faceva una volta StsckExchange?

Il problema principale sarebbe di dirlo chiaramente nella privacy policy che i post (o più precisamente i db dump) sono salvati in questo modo.

Ciò permetterebbe di migrare facilmente i contenuti in una nuova istanza Lemmy, se ve ne fosse bisogno, o di usarli come dataset per la ricerca (e, indirettamente, finalmente si formerebbe un dataset organico in Italiano di discreta qualità per il training di LLM).

[–] [email protected] 4 points 2 years ago (1 children)

I backup di Hetzner sono utilizzabili esclusivamente sulle loro macchine e, soprattutto, non sono in alcun modo scaricabili.

Si può pensare in futuro a fare dei backup di altro genere, io non ho assolutamente idea di come ma se salterà fuori qualcuno che vuole dare una mano e farlo se ne potrebbe discutere.

[–] [email protected] 3 points 2 years ago (2 children)

Purtroppo non ho ancora avuto abbastanza tempo linearmente coeso per immergermi nella documentazione di Lemmy, ma da una ricerca veloce ho visto nella documentazione presente su join-lemmy che i dati vengono immagazzinati in un database Postgresql.

Se hai accesso alla shell dell'host non dovrebbe esser complicato creare dei dump del database usando pgdump.

Purtoppo qui siamo sui bordi esterni del mio campo di competenza, quindi se qualcun altro mi può correggere?

[–] [email protected] 6 points 2 years ago

Se è basato su Postgres le opzioni sono illimitate. Pgdump, cdc live sulle tabelle, export parquet…

L’idea di averlo come dataset è fantastica. Se serve faccio queste cose per lavoro, magari in un momento più tranquillo darei volentieri una mano 😀

[–] sudneo 4 points 2 years ago* (last edited 2 years ago) (1 children)

Probabilmente non basta solo il dump del database per avere una copia direttamente funzionante, ma sicuramente è la parte più importante.

Direi che ci sono vari approcci:

Pgdump ogni tot
Pgbarman che usa un replication slot se uno vuole avere pieno PITR (Point in Time Recovery). Onestamente lo premetto, per un progetto del genere credo sia assolutamente accettabile avere chessò, 12h o anche 24h di potenziali dati persi nel caso uno dovesse fare il restore da backup. Quindi pgdump va più che bene a mio avviso.
Probabilmente un milioni di altri modi

Una volta che c'è il dump del DB, si prende quella e le altre directory utili, e si butta tutto dentro un repository restic/borg, che è cifrato e deduplicato. Si prende il repository e lo si sincronizza su https://www.borgbase.com/ (o Backblaze, o un'altra macchina qualsiasi - basta SSH).

Chiaramente questo è un modo, non Il modo, ma se @[email protected] è interessato a farsi una chiacchierata sull'argomento sarei felice di aiutare, anche praticamente.

[–] [email protected] 2 points 2 years ago (1 children)

Come dicevo più di un backup esiste già ed è anche dislocato su data center differenti e anche i vari snapshot sono distribuiti su altri data center, insomma a me sembra che su questo lato si è abbastanza protetti (per quanto non lo si è mai davvero abbastanza ovviamente).

Non so, chiedo anche a @[email protected] ma in questo momento mi sembra uno "sforzo" non necessario, ma non so se mi sbaglio o meno.

[–] sudneo 2 points 2 years ago

Assolutamente, l'idea non era principalmente per "ridurre il rischio", quanto per avere funzionalità diverse (che potrebbero non essere necessarie). Ad esempio poter scaricare o accedere liberamente ai backup, avere backup più piccoli (presumibilmente i backup ora sono dump di tutto il disco?), avere flessibilità nel gestire pruning (tipo tenere 1 backup mensile, 1 settimanale, 3 giornalieri etc.) e anche quello di poter estrarre singoli contenuti dai backup (magari questo è possibile già ora).

Non so poi quanto sia facile ad oggi testare la procedura di restore (serve prendere un altro vps?), ma con restic e simili uno può anche testare e scriptare la procedura in locale.

Da un punto di vista " i miei dati sono al sicuro" credo non ci siano problemi di sorta al momento, sembra essere tutto coperto!