[Talk-it] Server OSM di Backup Nazionali

Giovanni Mascellani g.mascellani at gmail.com
Wed Aug 26 21:48:30 BST 2009


Stefano de Fabris ha scritto:
> Giovanni Mascellani ha scritto:
>> Ci pensavo proprio nei giorni scorsi: la protezione da down è un
>> problema solo temporaneo (per quanto scocciante), ma se non abbiamo il
>> backup ed il disco si rompe i problemi sono ben maggiori, perché
>> dobbiamo ricominciare da capo.
>>
>>   
> Ci sono siti che già ora fanno il mirror pressoché giornaliero del 
> planet, altro discorso è il wiki, mailing-list, tracce gpx (dati non 
> meno importanti, a mio avviso).

Beh, wiki e mailing list sono molto più facili da backuppare. E se
dovessi decidere cosa perdere tra wiki, mailing list, gpx e dati OSM,
sicuramente sceglierei i primi tre! :-)

>> Si può organizzare un semi-backup distribuito semplicemente copiandosi
>> il planet ogni settimana, ma questo, in caso di morte del database
>> primario, ci permette di recuperare soltanto lo stato finale, non la
>> storia del database o i dati degli utenti. Un backup più serio sarebbe
>> molto consigliabile, grazie a Roberto per aver sollevato la questione.
>>
>>   
> Non so se il file planet contiene lo stato finale o anche lo storico, 
> questo sarebbe da verificare.

Su questo sono quasi del tutto sicuro: il planet contiene solo lo stato,
non lo storico. Del resto, non avrebbe molto senso scaricarsi ogni volta
la storia dell'intero progetto se vuoi offrire servizi basati sui dati
attuali.

>> Voi al momento avete idea di quanto sia grosso un dump completo del
>> database? A proposito, al momento i dati di OSM sono tenuti su MySQL o
>> PostgreSQL?
>>   
> Per quel che ne so io OSM usa PostgreSQL Il backup non dovrebbe essere 
> poi così enorme, essendo testo compresso (almeno nel formato che uso io 
> sul lavoro).

IL backup del database? Non so, ma dando un'occhiata alle dimensioni dei
dischi, direi che sotto il TB non si va (smaug, il database server ha 10
dischi da 450 GB). Non è roba molto facile da backuppare.

> Per darti un ordine di grandezza potrebbe essere comparabile con il file 
> planet.osm.bz2 stesso (a meno delle tracce gpx). Se non sono del tutto 
> idioti mi auguro che quelli della fondazione stiano già facendo un 
> backup giornaliero del database.

Me lo auguro anche io, ma mi chiedo dove. Non mi sembra il tipo di
database che si backuppa su una pennina USB. Non trovo da nessuna parte
alcuna evidenza che un backup sia effettivamente tenuto aggiornato.

> Diverso è fare un backup "continuo", ovvero avere una piena ridondanza 
> dei dati. Su questro non ho molta esperienza e non ho mai avuto 
> l'esigenza di provarlo.
> Per evitare perdite di dati sul lavoro l'accorgimento che uso è quello 
> di fare un backup ogni giorno quando lascio l'ufficio (tempo 1 minuto 
> per un backup di 50MB).

Io su un server che amministro eseguo un backup automaticamente ogni
quattro ore

>> Rimane il fatto che, invece, avere un backup (del database, non delle
>> tile) è un grosso problema.
>>
>>   
> Un backup delle tile è semplicemente inutile, visto che "derivano" dai dati.
> IMHO in caso di perdita delle immagini conviene rigenerarle piuttosto 
> che implementare un meccanismo per farne il backup.

Non è vero che è del tutto inutile: è inutile nell'ottica di preservare
i dati del database, ma è molto utile nell'ottica di continuare ad
offrire un servizio. Se costruisco un servizio Web che utilizza le tile
di OSM ed il server di OSM va giù io non posso più utilizzare il mio
servizio, cosa che non mi fa piacere. Vero che io non ho alcuna garanzia
da parte di OSM sull'affidabilità del servizio di fornitura delle tile,
però sarebbe bello provarci.

Riassumendo: secondo me la cosa migliore sarebbe avere un backup (senza
necessità di disponibilità immediata) per il database ed un qualche tipo
di ridondanza per la fornitura delle tile.

Ciaociao, Gio.
-- 
Giovanni Mascellani <g.mascellani at gmail.com>
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascellani at jabber.org / giovanni at elabor.homelinux.org
GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD  003F FCB0 BB5C 5F1F BF70)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 378 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20090826/69e0b15c/attachment.pgp>


More information about the Talk-it mailing list