On Mon, Sep 23, 2013 at 11:25:45AM +0200, Matteo Sgalaberni wrote:
> se hai una situazione con + tabelle e foreign key la cosa diventa più
> complessa. io obiettivamente rimarrei consolidando una procedura di backup
> che fa quello che voglio io... ma se vuoi affidarti al DBMS la soluzione più
> logica e comunque semplie è quella di usare il continuous archiving:
> http://www.postgresql.org/docs/9.1/static/continuous-archiving.html
Si`, questo e` quello da cui ero partito.
Questo schema di backup si basa sul principio:
we can combine a file-system-level backup with backup of the WAL files
siamo quindi nella situazione in cui copiamo i file fisici della
directory del DB, piu` i WAL.
A questo punto arriva il mio secondo problema: il programma ha bisogno
di accedere a dei dati storicizzati.
La soluzione che mi verrebbe piu` naturale sarebbe quella di mettere i
vari set di dati in DB diversi. Pero` sembra che non esista un metodo
semplice per fare un join tra tavole residenti in DB diversi, a meno di
usare un oggetto che si chiama dblink, ma che mi sembra di capire sia un
programma client-server, che viene generalmente usato per connettere DB
presenti su server diversi.
La soluzione che sembra essere piu` usata e` quella di mettere i vari
set di dati in schema diversi.
Tutti gli schema saranno attestati nello stesso DB, quindi quando
vado a backuppare il DB devo backuppare tutti gli schema, se non trovo
un metodo alternativo.
Questo per me vuol dire passare da un backup completo (giornaliero
notturno) di 4G ad uno di 16G.
Riassumendo:
1) Sembra che io debba usare il backup fisico dei file di
Postgres. Ogni suggerimento per limitare questo abominio e` ben accetto.
2) Questo metodo di backup mi costringe a backuppare tutti gli schema,
anche quelli che non variano. Esiste un modo per fare join tra DB (non
schema) diversi, che non introduca schifezze ulteriori?
--
Fernando Santagata
Jesus saves, but Buddha makes incremental backups.
|