UFFICIALE L'OT di Linux e altri OS

Pubblicità
Quindi quando si parla di gestione snapshots si parla di catturare l'istantanea solo della root giusto ?
In teoria potevi anche non gestire /dev/sdb1 come subvolume e tenerlo come semplice secondo disco fisico (e quindi 1 partizione) ?
Si parla di fare l'istantanea del subvolume X o Y, Timeshift supporta l'istantanea dei subvolume della radice e della home rinominati in @ e @home.
Era cosi prima, solo la radice (/dev/sdb1: /, dopo /dev/sdb1:/@dati e /dev/sdb1:/game, nessun subvolume, dopo mi è venuta l'idea di btrfs send, e quindi ho dovuto creare i subvolume per escludere le cartelle che non voglio fare backup.
 
Quindi quando si parla di gestione snapshots si parla di catturare l'istantanea solo della root giusto ?
No, si parla di fare l' istantanea del subvol chiamato in causa. Che contenga la root (/) oppure la home o... tu farai lo snap solo di quel subvol.
Va detta una cosa che finora è mancata. Prima di tutto non puoi fare lo snap (es. @root) e depositarlo in un altro nel subvol (es. @Dati). Potrai spostare lo snap solo con send/receive.
Se inizialmente lo snap pesa pochi KB perché è solo di metadati, nel momento in cui lo depositi da qualche altra parte (e per inciso BTRFS accetta solo BTRFS, in altri termini non puoi spostare con send/receive uno snap per metterlo in ext4 o altro filesystem), questi avrà la dimensione effettiva del sistema fotografato.
Semplificando ancora, se per esempio crei un subvol (es. @media), ci butti dentro 5 GB di files, fai lo snap, lo controlli e pesa 2MB, lo sposti nel disco esterno (sempre BTRFS), questi diverrà 5 GB, in pratica una copia 1:1.
Per spostarlo in altri filesystem devi creare un archivio e poi lo sposti con i soliti comandi di shell.

Bye^^
 
No, si parla di fare l' istantanea del subvol chiamato in causa. Che contenga la root (/) oppure la home o... tu farai lo snap solo di quel subvol.
Va detta una cosa che finora è mancata. Prima di tutto non puoi fare lo snap (es. @root) e depositarlo in un altro nel subvol (es. @Dati). Potrai spostare lo snap solo con send/receive.
Se inizialmente lo snap pesa pochi KB perché è solo di metadati, nel momento in cui lo depositi da qualche altra parte (e per inciso BTRFS accetta solo BTRFS, in altri termini non puoi spostare con send/receive uno snap per metterlo in ext4 o altro filesystem), questi avrà la dimensione effettiva del sistema fotografato.
Semplificando ancora, se per esempio crei un subvol (es. @media), ci butti dentro 5 GB di files, fai lo snap, lo controlli e pesa 2MB, lo sposti nel disco esterno (sempre BTRFS), questi diverrà 5 GB, in pratica una copia 1:1.
Per spostarlo in altri filesystem devi creare un archivio e poi lo sposti con i soliti comandi di shell.

Bye^^
l'aumento delle dimensione dello snapshot avviene anche sullo stesso file system man mano che la differenza dei file Y (snap) e Y (subvolume attuale) aumenta.
In pratica se elimini un file sul subvolume attuale, dopo lo snapshot Y, lo snapshot Y aumenta di dimensioni tanto quanto è la dimensione del file eliminato, perché rimane sullo snapshot.
--- i due messaggi sono stati uniti ---
E Timeshift ti mostra anche queste informazioni:
Schermata del 2020-01-31 22-15-03.webp
Dimensione è la dimensione effettiva del subvolume, Non condiviso è la dimensione dello snapshot
 
Ieri ho provato a fare il backup di /home su un HDD esterno tramite rsync... Ho dovuto interrompere, dovendo uscire, perchè dopo 2 ore stava ancora su ~/.local/share :asd:.
Mi sa che la prossima volta escluderò qualche cartella.
 
Ultima modifica:
gente, qualcuno di voi usa duplicity backup?

fino alla 0.7.19 non avevo problemi, la 0.8.9/0.8.10 (ultima stable) da errore
TypeError: a bytes-like object is required, not 'str'

per ora ho fixato con un downgrade manuale, ma vorrei capire la causa. sospetto ci sia lo zampino di python3, ma non sono sicuro (né so come intervenire)
 
gente, qualcuno di voi usa duplicity backup?

fino alla 0.7.19 non avevo problemi, la 0.8.9/0.8.10 (ultima stable) da errore


per ora ho fixato con un downgrade manuale, ma vorrei capire la causa. sospetto ci sia lo zampino di python3, ma non sono sicuro (né so come intervenire)
se hai il codice si potrebbe correggere l'errore. da qualche parte hanno ottenuto un oggetto binario credendo che fosse una stringa.
 
 
E anche Debian sta passando sotto la mia personalizzazione su Btrfs :patpat: Su Debian ha ancora più senso, visto che di default non crea nessun subvolume.
Inoltre escludendo molte cartelle dallo snapshot, grazie ai subvolumi, il subvolume della radice pesa davvero pochissimo.
Schermata del 2020-03-16 13-34-57.webp
 
Pubblicità
Pubblicità
Indietro
Top