Newsgroup: it.comp.os.win.windows10
Titolo: Cobian Backup Schedule e GUI

Prima che arrivi domenica e lo scopra da solo, l'interfaccia di cobian 
deve rimanere in esecuzione affinché i backup programmati vengano eseguiti?
 
In teoria dovrebbe bastare il servizio ma vorrei conferma.
Grazie
 
-- 
roughnecks

 In teoria dovrebbe bastare il servizio ma vorrei conferma.
 
Se non vado errato, basta il servizio
 

 
 
sul server funziona come servizio
l'utente administrator non è log-gato
l'interfaccia ovviamente non è aperta
 
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........

 l'interfaccia ovviamente non è aperta
 
Grazie per la conferma, non per altro ma non lo ho sottomano, anche
perchè ormai da tempo uso BareOS; non che Cobian sia malvagio, solo che
BareOS ha alcune caratteristiche che mi tornano piuttosto utili
 

 BareOS ha alcune caratteristiche che mi tornano piuttosto utili
 
andiamo a vederlo, allora :)


 andiamo a vederlo, allora :)
 
Una su tutte, "agent"
 
In breve ha un piccolo programma che si installa (su diversi OS) e gira
come "daemon" (servizio) e che gestisce la lettura dei dati dall'OS del
"client" (di backup) inviandoli in stream al server, in questo modo il
client NON ha alcuna visibilità dei supporti di backup, questo
significa che nel caso di "cryptosarcazzi" il supporto di backup NON
può essere incasinato (idem per altri malware); poi ok, c'è il supporto
WoL, spegnimento e diverse altre cosette
 

 
 
mi sembra bacula.


La Backup&Replication Suite in versione Community è
davvero eccellente.
 
Bye, G.
 
 
----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html
 


Non ti deve sembrare :-)
 
"Bareos is a 100% open source fork of the backup project from 
bacula.org
."
 
https://www.bareos.org/en/
 

 
https://www.bareos.org/en/
 
 
 
 
:-)
 
mi era scappata quella riga !
 
:-)

 
 
la ho provata giusto un paio di settimane fa, approfittando del giorno di 
ferie "degli altri"
 
installata su un server fisico ed eseguito il backup verso il NAS, creando 
anche la ISO per il ripristino
 
spero di non doverla mai usare nell'altra direzione ;)


 mi sembra bacula.
 
Infatti **E'** un fork di bacula :)
 
 

 spero di non doverla mai usare nell'altra direzione ;)
 
Dei backup vanno sempre, _sempre_, _*SEMPRE*_ effettuati
anche dei test di ripristino.
Perché anche quando funzionano, posso sempre esserci delle
sorprese sgradevoli.
 
Io l'ho imparato, per fortuna non a mie spese, svariati
anni fa. Ricordo ancora la faccia del collega quando un
certo server morì e lui dovette ripristinarlo.
Cerrrrrrrto, lui faceva religiosamente i backup tutti i
giorni da anni. Ed erano tutti a posto.
 
Piccolo problema: dopo il primo erano tutti (oltre un
migliaio...) rigorosamente incrementali.
 
Bye, G.

 migliaio...) rigorosamente incrementali.
 
Ed uno dei supporti era rovinato ... :) in effetti il discorso backup
viene spesso sottovalutato o considerato come una "rottura di scatole"
fino a che non succede qualcosa che obbliga ad effettuare un
ripristino, a quel punto il backup diventa improvvisamente "prezioso",
peccato che in molti casi, anche in aziende di una "certa dimensione"
NON venga implementata la verifica dei backup e la simulazione
periodica di ripristino che è fondamentale per assicurarsi che quanto è
stato copiato permetta realmente di recuperare i dati ottenendo un
sistema funzionante
 

 Ed uno dei supporti era rovinato ... :)
 
No, per fortuna no. Come detto erano tutti a posto (il che
in sé è già un piccolo miracolo, con la roba dell'epoca.
 
Ma rifletti un attimo sul meccanismo del ripristino di
backup incrementali - NON differenziali.
 
...dopo una settimana il sistema era ancora lì a macinare,
e lui lì a swappare tutto quel centinaio e rotti di CD =8-(


 
 
he he... no, in questo caso si tratta di una immagine dell'intero disco 
quindi niente incrementale o differenziale: se ne conservano giusto un paio 
di copie nel caso una diventasse inaccessibile
 
i dati (e la struttura/configurazione del database) hanno ovviamente backup 
diversi e ridondanti su supporti diversi


 e lui lì a swappare tutto quel centinaio e rotti di CD =8-(
 
Spero che per lo meno abbia imparato la lezione <vbeg> :D :D
 

 backup diversi e ridondanti su supporti diversi
 
Potresti anche crearti uno script per generare un backup "a caldo" del
DB in una cartella ed includere la cartella nella procedura di backup
normale, ti basterà schedulare il backup del DB in modo opportuno
 
 

 Spero che per lo meno abbia imparato la lezione <vbeg>
 
Lui non lo so, io sě. E questa č la seconda lezione.
Controllare, ricontrollare, poi verificare e infine accertarsi.
Poi far ricontrollare da qualcun altro.


 Poi far ricontrollare da qualcun altro.
 
Nel caso puoi sempre usare un "LART device" :D !
 
 

 
 
alla fine ce l'ha fatta a restorare ?
:-)

 Nel caso puoi sempre usare un "LART device" :D !
 
Mi toccherebbe fare Tafazzi... quello che materialmente
ha impostato quei job non è più con noi.
 
Nel senso che non lavora più con noi, ma da quello che
mi dicono potrebbe anche essere nell'altro senso, fra
un po'... problemi di salute, poveraccio :-(
 
Bye, G.

 :-)
 
Più saggio, più maturo e un bel po' più vecchio, ma so
che ce la fece.
 
Credo abbia avuto per un certo tempo degli incubi tipo
soldato di ritorno dal Vietnam, ogni volta che vedeva
un CD rabbrividiva e andava ad accarezzare il cane...
 
Bye, G.

 un po'... problemi di salute, poveraccio :-(
 
:(