Newsgroup: it.comp.software.database
Titolo: Sistema per backup disco on-line

Conoscete qualche sistema per copiare un intero disco, insomma tipo Ghost o 
Acronis True Image, su un server ftp o altro disco, MENTRE il sistema 
operativo ed un db server (Mysql, SqlServer, Firebird,..) stanno girando ???
Insomma, toccare niente delle impostazioni del sistema operativo e del db 
server, pensate sia possibile ottenere un hard-disk speculare o un'immagine 
su server ftp ?
Ciao e grazie
RobertoA

 stanno girando ???
Se intendevi a scopo di backup dei soli dati del db, ipotizzando che
non hai ben più complesse soluzioni di storage, e presupponendo
che hai messo in pratica la buona norma di partizionare i dati a
parte, si, è possibile; esistono soluzioni che fanno il backup a
caldo del db "col trucco": praticamente consistono in un mirroring
dei dischi ai quali temporaneamente viene "scollegato" un disco,
che sarà oggetto di backup. Successivamente verrà restituito al
mirroring, dove verrà resincronizzato.
Il vantaggio è l'illusione di avere un backup "istantaneo", con
minimo impatto sul server. Esse però sono soluzioni ad hoc
specifiche per un dbms e probabilmente anche specifiche per un HW.
Se volevi fare anche il backup del sistema operativo, credo che il
problema dei file bloccati, e ancora di più, dei buffer non scritti,
precluda tutto quanto. Almeno per una cosa "fatta come si deve".
bye

 specifiche per un dbms e probabilmente anche specifiche per un HW.
A cosa ti riferisci esattamente ???
Ciao e grazie
RobertoA

 A cosa ti riferisci esattamente ???
Mi riferisco ai cosiddetti Zero-Impact backup, di tipo Split Mirror.
Solitamente sono prodotti di terze parti, e non sono AFFATTO teneri
coi prezzi...
(Resto sempre perplesso nel dover sborsare soldoni per qualcosa
che imho dovrebbe essere già compreso nel software).
bye

 che imho dovrebbe essere già compreso nel software)
Questo dipende anche dalle tue necessita`. Per rimanere in tema,
qualsiasi database ti permette di fare un backup a caldo della base di
dati (gbak per Firebird/Interbase, pg_dump per PostgreSQL, mysqldump
per MySQL, exp per Oracle), backup che poi puoi riportare su nastro o su
qualche altro supporto in maniera veloce e indolore. Se poi le
necessita` sono altre (e.g. backup di tutti i file del db), allora e`
ovvio che i normali strumenti messi a disposizione dal db non sono piu`
sufficienti per eseguire il compito che ci siamo prefissi
Enrico

 sono piu` sufficienti per eseguire il compito che ci siamo prefissi
Non vedo perché il fare un backup di tutti i file del db, seppur
in maniera "evoluta", sia una necessità particolare. (Non è che
intendevi dbms?)
Imho le utility di backup si devono evolvere al pari del motore
del dbms, in quanto compendio essenziale ad esso; un backup che
dura ore è inaccettabile tanto quanto una base dati troppo lenta.
bye

 dura ore è inaccettabile tanto quanto una base dati troppo lenta.
Sinceramente non vedo cosa c'entri questo con il resto del discorso...
Enrico

 Sinceramente non vedo cosa c'entri questo con il resto del discorso...
Lo split mirroring nasce innanzitutto per problemi di prestazioni
nel fare i backup di basi dati molto grandi.
E' solo per (apparente, appunto) coincidenza che può essere quello
che serviva all'autore del messaggio originale.
bye

 ha scritto nel messaggio 
news:4593...@newsgate.x-privat.org...

Ci sono ad esempio i sistemi della Veritas, come le Snapshots (devi fermare 
xrò il db per il tempo necessario a tirarle su) o la datatabase edition..
Sono piuttosto carucci, xrò.. 

RobertoA ha scritto:

accessori -> utilita' di sistema -> backup
"L'utilità di backup esegue un'istantanea del volume dei dati per
creare una copia temporizzata accurata del contenuto dell'unità disco
rigido, che include tutti i file aperti o i file utilizzati dal
sistema. Gli utenti possono continuare ad accedere al sistema mentre
l'utilità di backup è in esecuzione senza correre il rischio che si
verifichino perdite di dati."
...
"Windows XP consente di creare backup della copia replicata del volume
e copie temporizzate esatte di file, inclusi i file aperti. Ad esempio,
durante il processo di backup della copia replicata del volume, viene
eseguito anche il backup dei database aperti in modo esclusivo e dei
file aperti per le attività di sistema o di un operatore. In questo
modo, i file modificati durante il processo di backup vengono copiati
correttamente.
I backup della copia replicata garantiscono quanto segue:
È possibile che le applicazioni continuino a scrivere dati anche
durante il processo di backup.
I file aperti non vengono esclusi dal processo di backup.
È possibile eseguire i processi di backup in qualsiasi momento, senza
bloccare altri utenti. "


"Writers: Preventing Data Inconsistencies
Writers are software that is included in applications and services
that help provide consistent shadow copies. Writers serve two main
purposes:
      • When applications and services are running, the writer responds
to signals provided by the Volume Shadow Copy Service interface to
allow applications to prepare and quiesce their data stores for shadow
copy creation and to ensure that no writes occur on the volume while
the shadow copy is being created. (During quiescence, applications
make data on the disk consistent [<- nota bene questo]. For example,
an application might flush its buffers to disk or write out in-memory
data to disk.)"
Per quale motivo il programma deve "prepararsi"? Per "Preventing Data
Inconsistencies", ovviamente. E che succede se il programma non
supporta tale interfaccia?
"Applications that are not shadow copy–enabled
If the computer has no applications that are enabled for the Volume
Shadow Copy Service, the data in a shadow copy is considered to be in
a “crash consistent” state. All files that were open will still exist,
but are not guaranteed to be free of incomplete I/O operations or
data corruption."
Queste ultime affermazioni mi sembra si chiudano con un tono ben
lontano da quello iniziale.
Il tutto si basa sull'assunto, parecchio pesante, che il
programma sia strutturato in un certo modo. pena la non validità
del backup.
byebye
(*) Idealmente la comunicazione potrebbe procedere così:
A (applicazione) - "Che bello, leggo scrivo come e quanto voglio"
B (programma di backup) - "Scusa caro, sto per backuppare tutto quanto"
A - scrive tutti i dati in memoria su disco; "Ok è tutto è pronto!"
B - backup di tutto quanto; "A posto, potete continuare"

 a "crash consistent" state.
mi sembra che quanto ho detto torna grosso modo con questo

 da subito e può perdurare indefinitamente.
Infatti, generalmente (vedi Oracle, ma anche ad esempio il db di Exchange) 
il sistema x effettuare un backup a caldo consiste nel bloccare (o per 
meglio dire, sospendere) le scritture sugli archivi per la durata del 
backup, memorizzando le transazioni sui logfiles che _non_ devono essere 
sovrascritti. Dopo aver salvato i files (così consistenti) dei dati, alla 
fine si procede con il salvataggio dei (redo)logs.

 fine si procede con il salvataggio dei (redo)logs.
In realta' si cercava di capire quali db fossero shadow copy enabled,
ossia compatibili con l'utility di backup di windows, fermo restando
che qualora non lo fossero, sarebbero con ogni probabilita' in grado di
recuperare da una situazione di crash (praticamente dell'applicazione,
il sistema operativo sarebbe recuperato senza problemi)