Re: [OT] Backup dati
Il 09/07/20 14:58, Alessandro Baggi ha scritto: > 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? > > Interessante questo thread anche se non ho letto tutto nei dettagli. Se il creatore di rsnapshot e' passato a borgbackup avrà buoni motivi ... magari dovrò darci un'occhiata in futuro. Sono due anni che uso rsnapshot senza problemi. E' semplice e sicuro. Antonio --- Respect your privacy and that of others, don't give your data to big corporations. Use alternatives like Signal (https://whispersystems.org/) for your messaging or Diaspora* (https://joindiaspora.com/) for your social networking.
Re: [OT] Backup dati
Il 10/07/20 20:29, Davide Prina ha scritto: 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 Buon giorno Lista, Si è quello. Mi piace molto. Ma ho provato il repository è funziona per Ubuntu ma non per Debian. Dove si trova un repository per Debian ? Io sto usando la versione 1.9.3 per Debian 9 su Buster. Mi sembra che nella versione 1.9.4 per Debian 10 (Buster) ci siano ancora dei bugs, quindi aspetto un po per installarla e provarla. Ciao Grazie
Re: [OT] Backup dati
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: [OT] Backup dati
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
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: [OT] Backup dati
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
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
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
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: [OT] Backup dati
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
Re: [OT] Backup dati
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
Re: [OT] Backup dati
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? > > 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. 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. Lo script, invece, mi da' parecchie soddisfazioni: stabile, costante, facile da manutenere e permette, vista propria la modalita' di salvataggio dei file di ritrovare le cose in tempi decisamente brevi. Che dire: come te sono un po' a un bivio: uso una applicazione mostro che pero' attraverso interfaccia decente consenta a utenti non smaliziati di sentirsi super uomini o continuo imperterrito a usare il mio script che decisamente mi fa dormire sonni molto piu' tranquilli. Inizio a pensare di concentrarmi di piu' sullo script. Mauro
[OT] Backup dati
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: [semi-OT] Backup dati
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pol Hallen ha scritto: | Vorrei sapere se ci sono filesystem appositi per questo tipo di | necessita' (o nel caso opzioni aggiuntive di sicurezza | ripristino). Beh, non penso che ci siano FS fatti apposta per i backup... certo pero' alcuni sono + adatti di altri, ma dipende da come e' fatto il backup: - -se ti crei dei tarball belli grossi (roba di centinaia di MB), allora ti serve un FS che dia il meglio con i file di grandi dimensioni (XFS potrebbe essere una buona soluzione) - -se semplicemente copi i file da un HD all'altro(metodo che non condivido, ma che molti usano, principalmente per motivi di velocita'), li' il discorso e' diverso: potresti avere molti tipi di file diversi. L'argomento era comunque stato gia' trattato nel thread quale fs scegliere per archiviare grandi volumi di dati http://lists.debian.org/debian-italian/2005/03/msg00358.html Davide -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCQXGzWY3RV1iWkPURAv8NAJ0QCQ2nfIOsE0Krxi4LnBChs4eqFgCePMuU 8eK+CzPJNxlP2tySvJ6NlUc= =hhLc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[semi-OT] Backup dati
Salve, avrei necessita' di avere un harddisk di backup. Attualmente uso ext3 con sarge, e non ho mai avuto problemi. Vorrei sapere se ci sono filesystem appositi per questo tipo di necessita' (o nel caso opzioni aggiuntive di sicurezza ripristino). Grazie :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
