Re: [OT] Backup dati

2020-07-10 Per discussione Davide Prina

On 10/07/20 15:17, Portobello wrote:


Systemback (anche se forse non è libero al 100%)


se è questo:
https://launchpad.net/systemback

allora sembra essere rilasciato con GPL 3.0 e quindi è software libero

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
I didn't use Microsoft machines when I was in my operational phase, 
because I couldn't trust them.
Not because I knew that there was a particular back door or anything 
like that, but because I couldn't be sure.

Edward Snowden



Re: chrome

2020-07-10 Per discussione Davide Prina

On 10/07/20 09:57, Filippo Dal Bosco - wrote:

Il giorno Thu, 9 Jul 2020 22:37:24 +0200
Davide Prina ha scritto:



le versioni recenti di molti browser stanno passando (o lo hanno già
fatto) da un'esecuzione monolitica a più thread. Ad esempio ogni
scheda aperta dovrebbe essere un processo distinto che man mano
diventa più isolato rispetto a tutto il resto del browser.


non mi sono spiegato bene.
Dopo aver usato chrome per il solo login alla rete rimane aperto sul
desktop ma non viene più usato perchè uso firefox con NoScript e
ghostery.

LA mia meraviglia viene dal fatto che pure semplicemente aperto sul
desktop si  "duplichi" e vada ad usare il 50% della cpu


sì, come dicevo varie parti del browser (intendo un browser generico che 
adotta tale tecnica) attivano un processo a sé stante.


Ora non mi sono informato su come avviene la creazione dei thread, ma di 
solito c'è un processo padre che genera i figli e controlla se sono 
vivi, se sono andati in crash, ... e agisce di conseguenza.


Poi tieni conto che quando attivi un browser ci sono varie attività che 
questo esegue anche se non lo usi (e ognuna di queste potrebbe essere un 
nuovo processo del browser):

* verifica se c'è una versione più recente
* verifica se i plugin installati hanno una versione più recente
* verifica se...
* esegue gli autoaggiornamenti di ciò che è impostato come 
autoaggiornabile (in Chrome dovrebbe essere tutto autoaggiornante)


Inoltre le stesse componenti che hai installato possono eseguire 
operazioni (es: se c'è installato un componente per il blocco della 
pubblicità può andare a prelevare l'ultima versione delle liste di 
blocchi che hai installato).


Infine, una cosa che mi sono dimenticato di dire ieri è relativa ai bug 
hardware, soprattutto delle CPU. Questi stanno avendo pesanti ricadute e 
modifiche dei sorgenti, per aggiungere mitigazioni ai bug (rendere 
l'attacco più complesso e difficile da realizzare), di svariati 
software, soprattutto per: microcode, kernel, compilatori, browser. 
Anche questo causa un aumento di uso di risorse. Se è vero che 
parzialmente si possono eliminare le mitigazioni (ad esempio non 
installando le ultime versioni del microcode per la propria CPU, 
disattivando alcuni parametri del kernel usato, per lo meno quelle che 
possono essere disabilitate o all'avvio o durante l'esecuzione), altre 
non si possono togliere così facilmente. Quelle presenti nel browser 
richiederebbero una ricompilazione con la disabilitazione di quelle 
parti (se possibile); inoltre essendo presenti tali mitigazioni anche 
nei compilatori bisognerebbe far compilare senza queste "aggiunte" messe 
dal compilatore durante la fase di compilazione.
Visto che queste mitigazioni dipendono dal processore che hai e che i 
processori maggiormente vulnerabili sono quelli Intel, soprattutto se 
hai un processore Intel è possibile che l'aumento di uso della CPU di un 
componente sia dovuto anche a questo problema.


Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Fate una prova di guida ... e tenetevi la macchina!:
http://linguistico.sf.net/wiki/doku.php?id=usaooo2
Non autorizzo la memorizzazione del mio indirizzo su outlook



Re: [OT] Backup dati

2020-07-10 Per discussione Alessandro Baggi



Il 10/07/20 15:54, Bertorello, Marco ha scritto:

Il 09/07/2020 15:58, Alessandro Baggi ha scritto:

Un saluto esteso a tutta la lista.

Come da oggetto ho necessità di mettere su un server di backup

[...]

Avete dei consigli al riguardo?


Non sto seguendo il thread, scusate, ma questo è stato rilasciato oggi
in Beta, magari vi interessa:

https://pbs.proxmox.com/wiki/index.php/Main_Page


Ciao e grazie per la risposta.

Grazie per aver condiviso, è molto interessante. +1



Re: [OT] Backup dati

2020-07-10 Per discussione Bertorello, Marco

Il 09/07/2020 15:58, Alessandro Baggi ha scritto:
> Un saluto esteso a tutta la lista.
>
> Come da oggetto ho necessità di mettere su un server di backup
[...]
>
> Avete dei consigli al riguardo?
>
Non sto seguendo il thread, scusate, ma questo è stato rilasciato oggi
in Beta, magari vi interessa:

https://pbs.proxmox.com/wiki/index.php/Main_Page

-- 
Marco Bertorello
https://www.marcobertorello.it




signature.asc
Description: OpenPGP digital signature


Re: chrome

2020-07-10 Per discussione Paolo Redaelli



Il 10 luglio 2020 09:57:32 CEST, Filippo Dal Bosco -  ha 
scritto:
>Il giorno Thu, 9 Jul 2020 22:37:24 +0200
>Davide Prina  ha scritto:
>
>
>> 
>> le versioni recenti di molti browser stanno passando (o lo hanno già 
>> fatto) da un'esecuzione monolitica a più thread. Ad esempio ogni
>> scheda aperta dovrebbe essere un processo distinto che man mano
>> diventa più isolato rispetto a tutto il resto del browser.
>
>non mi sono spiegato bene.
>Dopo aver usato chrome per il solo login alla rete rimane aperto sul
>desktop ma non viene più usato perchè uso firefox con NoScript e
>ghostery. 

Dopo aver eseguito l'accesso (login) non puoi chiudere Chrome?
Inoltre non puoi selezionare Firefox (o un altro da usare solo per il login) 
come navigatore predefinito così da evitare il doppio browser? 
Per queste cose io uso "Web" noto ai più come Epiphany, ossia il browser 
incluso in Gnome 
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.



Re: [OT] Backup dati

2020-07-10 Per discussione Portobello

Il 10/07/20 14:54, Giulio Turetta ha scritto:

backuppc

E' pacchettizzato per Debian, � solido e versatile.

Unica pecca? Non cripta i backup ma se la criptazione della partizione
che li contiene pu� essere sufficiente te lo consiglio.

Se invece la criptazione � un must vai un occhio a duplicity

Happy hack!

G.


Buon giorno Lista,
In quanto a semplicità io ho trovato ed utilizzo Systemback (anche se 
forse non è libero al 100%), ma funziona molto bene.
Faccio la copia della partizione completa dal disco A al disco B oppure 
al disco C. Le copie sono subito funzionanti, perché si copia tutto dati 
e sistema operativo, quindi sono avviabili. Copia anche la parte del 
menu di grub.
Quindi non è necessario fare il restore dei dati, che è la parte più 
critica del backup.


Grazie
Saluti



Il 09/07/20 15:58, Alessandro Baggi ha scritto:

Un saluto esteso a tutta la lista.

Come da oggetto ho necessit� di mettere su un server di backup per
effettuare il backup di un NAS (debian) con ~1TiB, qualche VPS
(potrebbero aumentare di numero) e una workstation. Sono tutti dati,
quindi niente immagini di VM o container.

Al momento ho in mano uno script (bash) da me scritto anni fa che
utilizza rsync per il backup di molteplici host tramite SSH. Utilizza
gli hardlink con l'opzione --link-dest e per ogni backup crea uno
snapshot a se stante. Inoltre ho la possibilit� di poter lanciare
degli script di pre/post job (sempre script in bash) sui target remoti
per operazioni (ES: lvm snapshot, backup di db, start/stop di
servizi...), ha il mailing, ha il pruning dei vecchi job, ha
un'impostazione per il QUOTA e il relativo controllo, crea un catalogo
dei file con alcune informazioni (su file) per ogni snapshot, permette
il restore dei backup sempre con rsync in un determinato path sul
target. Niente di complesso ma funziona. A casa lo uso con ZFS dove �
abilitata la compressione e dove ogni tanto lancio uno scrub per
verificare se ci sono degli errori. La cosa che mi piace � che i file
sono memorizzati nella stessa modalit� in cui sono scaricati, quindi
accessibili con qualsiasi tool disponibile sulla distro a non
dipendono da uno specifico software di backup ma solo dal filesystem.
Ha alcuni svantaggi come il limite degli hardlink, il gran numero di
file salvati singolarmente e non in un archivio per backup il che
potrebbe creare problemi con fsck. Oltre a queste non supporta la
compressione, la cifratura e il controllo di integrit� nativamente ma
al momento posso ovviare al problema grazie a ZFS e comunque essendo
uno script in bash preferirei gestire queste funzionalit� in maniera
pi� appropriata.

Per un ambiente lavorativo stavo pensado a qualcosa di pi�
professionale che supporti la compressione, deduplicazione (non che
sia necessaria al momento), cifratura dei backup e controllo di
integrit� dei backup.

Facendo un ricerca in rete ho trovato:

1) rsnapshot: non pi� mantenuto in quanto lo sviluppatore principale �
passato a borgbackup.
2) dirvish: non pi� mantenuto dal 2014.
3) bacula: letteralmente un mostro (che ho usato in passato)
4) bareos: � il fork di bacula quindi come sopra
5) amanda: non so
6) borgbackup: tool veramente interessante ma supporta solo il push
nativamente quindi dovrei usarlo con rsync + borg in locale. Anche in
questo caso uno script bash � necessario per mantenere pi� client.
7) restic: simile a borgbackup

e altri.

Avete dei consigli al riguardo?

Scusate la lunghezza e grazie.

Alessandro.








Re: [OT] Backup dati

2020-07-10 Per discussione Alessandro Baggi

Il 10/07/20 14:54, Giulio Turetta ha scritto:

backuppc

E' pacchettizzato per Debian, è solido e versatile.

Unica pecca? Non cripta i backup ma se la criptazione della partizione
che li contiene può essere sufficiente te lo consiglio.

Se invece la criptazione è un must vai un occhio a duplicity

Happy hack!

G.


Ciao Giulio,

grazie per la risposta e per il suggerimento.

Un saluto, Alessandro.



Re: [OT] Backup dati

2020-07-10 Per discussione Alessandro Baggi



Il 10/07/20 12:21, Mauro Morichi ha scritto:



Il 10/07/2020 10:27, Alessandro Baggi ha scritto:

mile al tuo, con checksum, quota, notifiche e comunicazioni.
Come hai implementato il checksum nel tuo script? Io sto provando a 
trovare una soluzione utilizzando l'md5 di rsync che si può ottenere 
usando l'opzione --output-format="%C e altri format per altre info". 
Questo è ottimo perche cmq l'hash lo calcola direttamente rsync e si 
risparmia un po di tempo, quindi per ogni file scaricato inserisco il 
rispettivo md5 in un manifest unico per il client contenente tutti i 
checksum dei file scaricati precedentemente. Il problema è che usando 
gli hardlink e utilizzando il prune, mi ritrovo a dover aggiornare 
una lista molto lunga ogni volta che effettuo un prune e questo 
richiede molto tempo. Al momento mi sono affidato a ZFS ma se non ho 
capito male il controllo di zfs consiste nel controllare se la copia 
live è cambiata rispetto a quella della parità senza che il file sia 
stato modificato nella copia live (anche perche se il file viene 
modificato nella copia live viene comunque aggiornato anche nel 
parity) (se sbaglio correggetemi).
anche se piu' lentamente utilizzo il tool esterno. Ogni volta genero 
un file con l'elenco di tutti gli md5 piu' altre info utili come 
spazio occupato, spazio disponibile, numero di backup presenti un 
po' di info leggibili, insomma.


Anche io ho provato con un tool esterno (sha512/256sum) ma quando sono 
molti file (tipo il primo backup o un aggiornamento di qualche giga) ci  
mette un po. Per esempio il primo backup scarica circa 60 file e  il 
processo per calcolare il checksum di ogni file richiede un bel po di 
tempo mentre invece utilizzando il checksum (md5 al momento) di rsync si 
perde solo il tempo di sincronizzazione dei file.




Re: [OT] Backup dati

2020-07-10 Per discussione Giulio Turetta
backuppc

E' pacchettizzato per Debian, è solido e versatile.

Unica pecca? Non cripta i backup ma se la criptazione della partizione
che li contiene può essere sufficiente te lo consiglio.

Se invece la criptazione è un must vai un occhio a duplicity

Happy hack!

G.

Il 09/07/20 15:58, Alessandro Baggi ha scritto:
> Un saluto esteso a tutta la lista.
>
> Come da oggetto ho necessità di mettere su un server di backup per
> effettuare il backup di un NAS (debian) con ~1TiB, qualche VPS
> (potrebbero aumentare di numero) e una workstation. Sono tutti dati,
> quindi niente immagini di VM o container.
>
> Al momento ho in mano uno script (bash) da me scritto anni fa che
> utilizza rsync per il backup di molteplici host tramite SSH. Utilizza
> gli hardlink con l'opzione --link-dest e per ogni backup crea uno
> snapshot a se stante. Inoltre ho la possibilità di poter lanciare
> degli script di pre/post job (sempre script in bash) sui target remoti
> per operazioni (ES: lvm snapshot, backup di db, start/stop di
> servizi...), ha il mailing, ha il pruning dei vecchi job, ha
> un'impostazione per il QUOTA e il relativo controllo, crea un catalogo
> dei file con alcune informazioni (su file) per ogni snapshot, permette
> il restore dei backup sempre con rsync in un determinato path sul
> target. Niente di complesso ma funziona. A casa lo uso con ZFS dove è
> abilitata la compressione e dove ogni tanto lancio uno scrub per
> verificare se ci sono degli errori. La cosa che mi piace è che i file
> sono memorizzati nella stessa modalità in cui sono scaricati, quindi
> accessibili con qualsiasi tool disponibile sulla distro a non
> dipendono da uno specifico software di backup ma solo dal filesystem.
> Ha alcuni svantaggi come il limite degli hardlink, il gran numero di
> file salvati singolarmente e non in un archivio per backup il che
> potrebbe creare problemi con fsck. Oltre a queste non supporta la
> compressione, la cifratura e il controllo di integrità nativamente ma
> al momento posso ovviare al problema grazie a ZFS e comunque essendo
> uno script in bash preferirei gestire queste funzionalità in maniera
> più appropriata.
>
> Per un ambiente lavorativo stavo pensado a qualcosa di più
> professionale che supporti la compressione, deduplicazione (non che
> sia necessaria al momento), cifratura dei backup e controllo di
> integrità dei backup.
>
> Facendo un ricerca in rete ho trovato:
>
> 1) rsnapshot: non più mantenuto in quanto lo sviluppatore principale è
> passato a borgbackup.
> 2) dirvish: non più mantenuto dal 2014.
> 3) bacula: letteralmente un mostro (che ho usato in passato)
> 4) bareos: è il fork di bacula quindi come sopra
> 5) amanda: non so
> 6) borgbackup: tool veramente interessante ma supporta solo il push
> nativamente quindi dovrei usarlo con rsync + borg in locale. Anche in
> questo caso uno script bash è necessario per mantenere più client.
> 7) restic: simile a borgbackup
>
> e altri.
>
> Avete dei consigli al riguardo?
>
> Scusate la lunghezza e grazie.
>
> Alessandro.
>
>



Re: chrome

2020-07-10 Per discussione WinterMute
il Fri, 10 Jul 2020 09:57:32 +0200
Filippo Dal Bosco -  ha scritto:

| non mi sono spiegato bene.
| Dopo aver usato chrome per il solo login alla rete rimane aperto sul
| desktop ma non viene più usato perchè uso firefox con NoScript e
| ghostery. 
| 
| LA mia meraviglia viene dal fatto che pure semplicemente aperto sul
| desktop si  "duplichi" e vada ad usare il 50% della cpu 

buon pomeriggio,

non uso chrome quindi non ti saprei dire nello specifico tuttavia forse si
potrebbero ottenere info maggiori usando dei tool quasi "netstat" e/o "lsof".
per capire meglio cosa sta facendo il processo "incriminato".

saluti.

***
║ »» WinterMute «« ║ -> https://www.debian.org/  «branch» bullseye/testing
║ GNU  Project ║ -> https://www.gnu.org/   
║ Kernel  Archives ║ -> https://www.kernel.org/
║ GPG  FingerPrint ║ -> 38A4 5354 30C5 E86F 9AA8  B234 7227 D71D A547 39E0
***


pgpNFuQQucc5p.pgp
Description: Firma digitale OpenPGP


Re: [OT] Backup dati

2020-07-10 Per discussione Mauro Morichi

Il 10/07/2020 10:27, Alessandro Baggi ha scritto:
> mile al tuo, con checksum, quota, notifiche e comunicazioni.
> Come hai implementato il checksum nel tuo script? Io sto provando a
> trovare una soluzione utilizzando l'md5 di rsync che si può ottenere
> usando l'opzione --output-format="%C e altri format per altre info".
> Questo è ottimo perche cmq l'hash lo calcola direttamente rsync e si
> risparmia un po di tempo, quindi per ogni file scaricato inserisco il
> rispettivo md5 in un manifest unico per il client contenente tutti i
> checksum dei file scaricati precedentemente. Il problema è che usando
> gli hardlink e utilizzando il prune, mi ritrovo a dover aggiornare una
> lista molto lunga ogni volta che effettuo un prune e questo richiede
> molto tempo. Al momento mi sono affidato a ZFS ma se non ho capito
> male il controllo di zfs consiste nel controllare se la copia live è
> cambiata rispetto a quella della parità senza che il file sia stato
> modificato nella copia live (anche perche se il file viene modificato
> nella copia live viene comunque aggiornato anche nel parity) (se
> sbaglio correggetemi). 
anche se piu' lentamente utilizzo il tool esterno. Ogni volta genero un
file con l'elenco di tutti gli md5 piu' altre info utili come spazio
occupato, spazio disponibile, numero di backup presenti un po' di
info leggibili, insomma.
> Concordo. Bacula è una cosa allucinante, l'ho usato in passato con
> successo ma è troppo complesso e macchinoso (magari in altre realtà è
> la salvezza ed è necessario che sia cosi). Prima cosa è un pò
> confusionario il modo in cui i client vengono configurati, cioè si
> parte da un file di configurazione che contiene le direttive ma poi
> una parte delle info viene memorizzata sul database (la parte
> riguardante ai pool, volumi, job, file e host). Non c'è niente di male
> in questo ma se provi cambiare le config dei pool, volumi ecc devi cmq
> aggiornarle sul DB con la bconsole, se elimini un client dalla
> configurazione poi devi andare ad eliminare il client dal DB, idem se
> fai modifiche ai pool/volumi, idem se cancelli un volume o un job
> (esiste un tool per fare questo, o meglio un tool che si occupa di
> eliminare i record orfani ma non ha mai funzionato per me..sarò io).
> Poi ci sta il mantenimento del DB che potrebbe diventare gigante e
> quindi le query per vedere quale file è memorizzato in quale volume
> richiedo un tempo maggiore e poi ti ritrovi a fare un backup del db
> (di bacula) molto grande (ci sono diverse direttive per questo ma si
> può sempre omettere qualcosa o sbagliare il retention period). Oltre a
> questo non mi piace come gestisce i volumi sui backup con storage su
> disco e non su TAPE (su TAPE penso che sia formidabile questo
> approccio) ma su disco è più un problema che una soluzione. Per
> esempio, mi capitava che un job fallisse per un motivo ma il volume
> era già stato allocato e marcato come usato. Avendo il maximum volume
> jobs = 1, Maximum Volumes = N e le retention policy praticamente
> distruggeva il ciclo di backup del client perche ti trovavi con un
> volume in meno  (praticamente non usato) ma che cmq ti sballava il
> ciclo. E vai a manina a cambiare il numero di pool per fargli fare il
> backup e poi eliminare quello vecchio. Forse lo usavo male io, ma per
> backup su disco non è il massimo. Poi per carità ha delle funzioni
> spettacolari come il migration su un secondo storage come replica,
> backup virtuali ecc...forniscono supporto a chi ne ha bisogno ma il
> gioco non vale la candela (nel mio caso). Per non parlare del caso in
> cui il server crepa, o il DB crepa, o i volumi corrotti. Prova a
> ricostruire il db dai volumi senza il bootstrap (con bscan) e vedi
> quanto ci mette.Ah e ci sta anche un altro problema. Se io
> implemento un sistema con bacula per qualcuno, e poi non sono più il
> responsabile per varie ragioni, quello che dovrà far funzionare i
> backup dovrà impazzire per imparare bacula in un tempo ragionevole o
> rimpiazzare la soluzione di backup. Non che sia un mio problema ma
> lasciare un cliente in una situazione del genere non mi piace.


Bareos dovrebbe, almeno sulla carta, risolvere i problemi storici di
Bacula. In realta', e questo l'ho capito sbattendoci le corna, i file di
configurazione servono solo per generare le configurazioni vere e
proprio memorizzate nei db. Sto giusto cercando di capire quanto i
plugin di python possono essere utili in questo contesto.

Resta la sua complessita'. Unico passo in avanti e', almeno nella
configurazione debian, l'aver esploso tutti i file di configurazioni
suddividendo ogni componente in un file a se, sicuramente piu'
manutenibile rispetto al file monolitico di bacula che alla fine non ci
si capiva piu' nulla.

Resta un po' il discorso di come i dati vengono gestisti fisicamente.
Non ho possibilita' di usare unita' a nastro, purtroppo, e i limiti dei
file si vedono abbastanza velocemente.

> Anche io sto avendo grandi soddisfazione dal mio s

Re: [OT] Backup dati

2020-07-10 Per discussione Alessandro Baggi


Il 09/07/20 21:48, Mauro ha scritto:

Il 09/07/2020 15:58, Alessandro Baggi ha scritto:

Un saluto esteso a tutta la lista.



ricambio con piacere.



Per un ambiente lavorativo stavo pensado a qualcosa di più
professionale che supporti la compressione, deduplicazione (non che
sia necessaria al momento), cifratura dei backup e controllo di
integrità dei backup.

Facendo un ricerca in rete ho trovato:

1) rsnapshot: non più mantenuto in quanto lo sviluppatore principale è
passato a borgbackup.
2) dirvish: non più mantenuto dal 2014.
3) bacula: letteralmente un mostro (che ho usato in passato)
4) bareos: è il fork di bacula quindi come sopra
5) amanda: non so
6) borgbackup: tool veramente interessante ma supporta solo il push
nativamente quindi dovrei usarlo con rsync + borg in locale. Anche in
questo caso uno script bash è necessario per mantenere più client.
7) restic: simile a borgbackup

e altri.

Avete dei consigli al riguardo?



Ciao Mauro e grazie per la risposta

La mia situazione che e' un mix di robe di lavoro e personali alla fine
mi hanno portato a usare due tools (tralascio quelli per gli ambienti
misti winz):

il primo, uno script che ogni giorno cresce un po' che si basa su rsync,
simile al tuo, con checksum, quota, notifiche e comunicazioni.
Come hai implementato il checksum nel tuo script? Io sto provando a 
trovare una soluzione utilizzando l'md5 di rsync che si può ottenere 
usando l'opzione --output-format="%C e altri format per altre info". 
Questo è ottimo perche cmq l'hash lo calcola direttamente rsync e si 
risparmia un po di tempo, quindi per ogni file scaricato inserisco il 
rispettivo md5 in un manifest unico per il client contenente tutti i 
checksum dei file scaricati precedentemente. Il problema è che usando 
gli hardlink e utilizzando il prune, mi ritrovo a dover aggiornare una 
lista molto lunga ogni volta che effettuo un prune e questo richiede 
molto tempo. Al momento mi sono affidato a ZFS ma se non ho capito male 
il controllo di zfs consiste nel controllare se la copia live è cambiata 
rispetto a quella della parità senza che il file sia stato modificato 
nella copia live (anche perche se il file viene modificato nella copia 
live viene comunque aggiornato anche nel parity) (se sbaglio correggetemi).

il secondo un bacula che sta diventando in questi giorni un bareos.
Quest'ultima soluzioni l'avevo scelta qualche anno fa perche' dovevo
lavorare in ambienti misti (linux,bsd e windows) e mi sembrava una
valida alternativa da mettere in mano con apposita interfaccia a utenti
meno smaliziati a cui, al massimo, dovevo far premere un tasto soltanto.

Effettivamente Bareos/Bacula sono di una complessita' che rasenta la
follia. Per carita' stabili, ma laddove ho thera e thera di file piccoli
(documenti office) andare a cercare qualcosa sta diventando una tortura.
Concordo. Bacula è una cosa allucinante, l'ho usato in passato con 
successo ma è troppo complesso e macchinoso (magari in altre realtà è la 
salvezza ed è necessario che sia cosi). Prima cosa è un pò confusionario 
il modo in cui i client vengono configurati, cioè si parte da un file di 
configurazione che contiene le direttive ma poi una parte delle info 
viene memorizzata sul database (la parte riguardante ai pool, volumi, 
job, file e host). Non c'è niente di male in questo ma se provi cambiare 
le config dei pool, volumi ecc devi cmq aggiornarle sul DB con la 
bconsole, se elimini un client dalla configurazione poi devi andare ad 
eliminare il client dal DB, idem se fai modifiche ai pool/volumi, idem 
se cancelli un volume o un job (esiste un tool per fare questo, o meglio 
un tool che si occupa di eliminare i record orfani ma non ha mai 
funzionato per me..sarò io). Poi ci sta il mantenimento del DB che 
potrebbe diventare gigante e quindi le query per vedere quale file è 
memorizzato in quale volume richiedo un tempo maggiore e poi ti ritrovi 
a fare un backup del db (di bacula) molto grande (ci sono diverse 
direttive per questo ma si può sempre omettere qualcosa o sbagliare il 
retention period). Oltre a questo non mi piace come gestisce i volumi 
sui backup con storage su disco e non su TAPE (su TAPE penso che sia 
formidabile questo approccio) ma su disco è più un problema che una 
soluzione. Per esempio, mi capitava che un job fallisse per un motivo ma 
il volume era già stato allocato e marcato come usato. Avendo il maximum 
volume jobs = 1, Maximum Volumes = N e le retention policy praticamente 
distruggeva il ciclo di backup del client perche ti trovavi con un 
volume in meno  (praticamente non usato) ma che cmq ti sballava il 
ciclo. E vai a manina a cambiare il numero di pool per fargli fare il 
backup e poi eliminare quello vecchio. Forse lo usavo male io, ma per 
backup su disco non è il massimo. Poi per carità ha delle funzioni 
spettacolari come il migration su un secondo storage come replica, 
backup virtuali ecc...forniscono supporto a chi ne ha bisogno ma il 
gioco non vale la candela (nel mio

Re: chrome

2020-07-10 Per discussione Filippo Dal Bosco -
Il giorno Thu, 9 Jul 2020 22:37:24 +0200
Davide Prina  ha scritto:


> 
> le versioni recenti di molti browser stanno passando (o lo hanno già 
> fatto) da un'esecuzione monolitica a più thread. Ad esempio ogni
> scheda aperta dovrebbe essere un processo distinto che man mano
> diventa più isolato rispetto a tutto il resto del browser.

non mi sono spiegato bene.
Dopo aver usato chrome per il solo login alla rete rimane aperto sul
desktop ma non viene più usato perchè uso firefox con NoScript e
ghostery. 

LA mia meraviglia viene dal fatto che pure semplicemente aperto sul
desktop si  "duplichi" e vada ad usare il 50% della cpu 

 


-- 
Filippo



Re: chrome

2020-07-10 Per discussione Portobello

Il 09/07/20 22:37, Davide Prina ha scritto:

On 09/07/20 19:56, Filippo Dal Bosco - wrote:

Su bullseye uso chrome



mi capita
con top di vedere due chrome ed uno che ogni tanto usa il 50% di cpu


le versioni recenti di molti browser stanno passando (o lo hanno già 
fatto) da un'esecuzione monolitica a più thread. Ad esempio ogni scheda 
aperta dovrebbe essere un processo distinto che man mano diventa più 
isolato rispetto a tutto il resto del browser.
In questo modo se va in crash una parte viene stoppato (o dovrebbe 
essere stoppato) solo il processo del thread che ha causato il problema, 
mentre tutto il resto dovrebbe continuare a funzionare senza problemi. 
Inoltre tale isolamento dovrebbe impedire ad una parte di "spiare" 
quello che viene fatto nelle altre parti e questo potrebbe portare ad un 
miglioramento della sicurezza.


Questa gestione però ha anche degli aspetti che potrebbero essere 
negativi, come l'aumento uso risorse.


Proprio per un aumento di uso di risorse potrebbe aumentare la 
probabilità che parte o tutto quello che è in esecuzione nel browser 
venga messo in swap e rimesso in memoria quando si accede a quella 
parte. Questa operazione potrebbe far innalzare momentaneamente l'uso di 
CPU/disco e per i sistemi un po' datati causare rallentamenti.



Mi viene il sospetto che chrome "inattivo" sia invece attivo a "favore"
di google.


questo sospetto potresti eliminando installando chromium, che non è 
altro che la parte base rilasciata con licenza libera dal quale viene 
ricavato chrome.


In ogni caso se usi chrome i dati della navigazione, utilizzo e altro 
vengono spediti di sicuro a google, ma probabilmente anche ad altri 
(dietro pagamento). Ti faccio presente che questi dati possono essere 
utilizzati per identificare un utente in modo univoco o quasi (o 
comunque possono contribuire in questa identificazione) eliminando anche 
la tua privacy, soprattutto per quanto riguarda il tracciamento, 
profilazione e collegamento dei siti che visiti con "quello che tu sei", 
ricavando anche "ipotesi" su dati personali sensibili, come quelli medici.


Infine negli USA è in atto un processo (action class) contro google, 
proprio per chrome, perché nei tab anonimi sembra che l'anonimato non 
sia stato rispettato. La class action chiede almeno 5 miliardi di 
dollari di risarcimento[¹].


Senza contare che da questo mese sono entrate a pieno regime le 
normative sulla privacy della California e del Sud Africa. Interessante 
quella della California perché permette agli utenti, tramite un'entità 
intermedia, di richiedere il pagamento alle aziende se vogliono usare i 
loro dati. Qualcosa del genere: se google vuole usare i miei dati, io do 
mandato all'unione consumatori di richiedere il pagamento di X $ (penso 
all'anno). Naturalmente questa legge vale per i californiani, ma, in 
teoria, può essere applicata a qualsiasi servizio web esposto da 
qualsiasi parte del mondo che raccoglie e usa dati personali e a cui i 
californiani hanno accesso


Buon giorno a tutta la Lista,
Che io sappia c'è anche una class action di altroconsumo.it contro 
Facebook per motivi simili.


Saluti



Ciao
Davide

[¹] ho cercato con https://www.duckduckgo.com una stringa come questa: 
"class action google privacy" e questo è uno dei primi risultati
https://www.forbes.com/sites/daveywinder/2020/06/03/google-chrome-privacy-lawsuit-could-you-get-a-5000-payout-incognito-mode-class-action/