[gl-como] Gestione Backup

[Francesco Angelo Brisa]

forse intendevi burp .... io l'ho usato un pochino e non è male

comunque per ora principalmente uso rsync in remoto, facendo in modo che
rsync tenga una versione dei file...

mi ero fatto un programmino, dal codice puoi vedere come usare rsync per
questo
http://www.setterirlandesi.it/ubs.tar.gz

l'unico problema è che così facendo se cambi anche solo un bit, viene
creata sul backup un intera copia del file (Mentre burp fa solo le
differenze)



Il giorno 22 novembre 2017 09:16, Elena ``of Valhalla'' <
valhalla-l@trueelena.org> ha scritto:

> On 2017-11-22 at 00:10:00 +0000, Matteo wrote:
> > Per dare un po' di contesto alla questione la situazione e` la seguente:
> > - file non particolarmente importanti ma che occupano un bel po' di
> spazio
> > - file importanti
> > - memoria del laptop da liberare (eliminando appunto i file non
> importanti)
> > - due dischi disponibili per backup (uno piu` grosso dell'altro)
> > - evitare gestione manuale di tutto (si`, si possono fare directory per
> > ogni copia, controllare la data di creazione eccetera ma non e` questo
> > lo scopo)
> > - minimizzare i tempi di copia (quindi la mole di dati da trasferire
> > ogni volta)
> > [...]
> > Ho pensato di fare tipo un git repo ma
> > - occupa un bel po' di spazio
> > - non e` uno strumento nato per questo tipo di esigenza
>
> Io ho una soluzione ibrida tra backup e sincronizzazione dei file che è
> basata su git (per i file relativamente piccoli, che cambiano e di cui
> tengo lo storico), git-annex (per i file più grossi e che vengono
> aggiunti o tolti, ma non cambiano contenuti) e vcsh (per i file di
> configurazione), più mr (myrepos) per gestire tutto in massa
>
> Oltre agli hard disk però c'è anche un serverino centrale: non è
> indispensabile, ma rende più comodo fare i push mentre sto lavorando
> senza dover stare ad attaccare un disco.
>
> L'idea è che per ogni progetto ho un repository git, fin dall'inizio, e
> quasi subito questo repository viene aggiunto ai repository bare sul
> serverino e all'elenco di repository gestito da mr.
> La stessa cosa per le raccolte di file (foto, musica, video, ebook,
> ecc.): ciascuna raccolta ha un suo repository git-annex, un
> corrispondente git bare sul serverino e un entry in mr.
>
> I push e le copie di file nel mio caso sono manuali: mentre lavoro sto
> comunque interagendo con git e mi viene naturale fare i push, e quando
> aggiungo file alle raccolte faccio anche la copia, sia verso il
> serverino che in alcuni casi verso dischi esterni. È comunque un
> comando, non una cosa complicata come la gestione di directory con le
> date ecc.
> Per git-annex si potrebbe automatizzare la sincronizzazione con
> l'assistant, ma non ne ho mai sentito il bisogno.
>
> Il bello di git-annex è che gestisce anche il fatto di avere copie
> parziali del repository: uno può avere una copia sul portatile in cui
> c'è l'elenco dei file, ma senza i loro contenuti (che occupano tanto
> spazio), e prendersi solo quei contenuti di cui ha bisogno in quel
> momento, e avere una copia completa su un disco esterno o simili.
> git-annex stesso gestisce il fatto di avere sempre almeno N copie dei
> file, impedendoti di cancellare l'ultima copia (o una delle N ultime)
> dei contenuti da uno dei repo fino a che non è sicuro che non ce li
> abbiano gli altri.
>
> L'unica cosa che ho automatizzato è che i repository git sul serverino
> vengono automaticamente mirrorati su un serverino a 30 km di distanza e
> 30 metri sotto il suolo, come da buone pratiche per il backup (sto
> ancora lavorando su quello a 30 km di distanza da entrambi e 30 metri da
> terra). (ok, forse le distanze verticali sono un po' esagerate :) )
>
> Con tutto ciò ho già ripristinato la /home del mio portatile un paio di
> volte, con un comando tipo ``mr -c .mr/TUTTO.mr checkout`` (o, per il
> portatile che porto in giro ``mr -c .mr/si_cipolla_no_piccante.mr
> checkout``) e un po' di attesa mentre clonava repository (ma senza il
> trasferimento dei file grossi degli annex, che invece ho fatto poi alla
> bisogna — riducendo quindi di molto la necessità di trasferimento file
> prima di poter ricominciare a lavorare).
>
> > Ho trovato/qualcuno di voi me ne ha parlato/non ricordo questo:
> > - bup[0]
>
> Io l'ho usicchiato per fare backup di alcuni file (log di chat), ma non
> so se sono convintissima, stavo meditando di provare borg al suo posto,
> che al momento pare essere la cosa consigliata in giro.
>
> > Sembra fare cio` che mi interessa ma:
> > - E` consigliato/possibile copiare tutto (ad esempio tutta la
> > /home/user) e poi dire a bup di escludere dall'aggiornamento i file non
> > importanti o le due copie devono essere identiche? Da un git repo
> > normale non mi pare sia un problema. Questo poi non crea problemi nel
> > riclonare la copia ad un eventuale disco nuovo?
>
> I file che non cambiano non vengono ricopiati (ma questo credo che sia
> il comportamento standard di tutti i programmi di backup che supportano
> modalità incrementale)
>
> > - Non mi pare abbia un modo di creare snapshot da cui si puo` tornare ad
> > una copia precedente (no, riclonare il repo non e` una soluzione
> > ammissibile)
>
> https://github.com/bup/bup
>
>    You can mount your bup repository as a FUSE filesystem and access the
>    content that way, and even export it over Samba.
>
> --
> Elena ``of Valhalla''
>
>
> --
> Mailing list info: https://lists.linux.it/listinfo/gl-como
>
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.linux.it/pipermail/gl-como/attachments/20171122/6320958e/attachment-0001.html>