UFFICIALE L'OT di Linux e altri OS

[Utente cancellato 110428]

A parte KDE direi che andava bene, però ho commesso l'errore di installarlo su una partizione troppo piccola per poter sfruttare BTRFS, con il risultato che ero sempre al limite

EDIT: codeblocks andava in palla :asd:

Uh, un altro utente di codeblocks ;-D.

@AES Alla fine se non crei un subvol dedicato alla home, in fase d' installazione la $HOME/<user> verrà creata dal sistema con' adduser -m'. Quindi non puntando a una partizione o subvol separato, quando snappi il subvol @root (o come l' hai chiamato) ...lo fa di tutto, home compresa.
Piuttosto dovrai vedere le impostazioni del programma che andrai a usare per gli snapshot, che non sia come ha scritto sopra, che in Ubuntu di default cerca il subvol @home.

EDIT: Ma in questo forum c'è un utente col nick root? Ma LOL

Eh, sì, appunto, normalmente root comprende anche gnome se tutto viene messo in /. Perdonate le ovvietà, ma certe volte ho bisogno di essere sicuro al 150%

 

[« MoMy »]

Non ho esperienza, btrfs lo uso da poco e non ho ancora creato uno snap quindi non ho l' assoluta certezza. Mi chiedo se sia possibile visionare il contenuto di uno snapshot.

EDIT: Ho fatto una prova con snapper.
Al tempo nel Pandino avevo creato la subvol @root e @home. Seguendo il wiki di Arch ho creato la config per la sola @root e lanciato il comando per lo snap.
Il sistema ha creato in / la path nascosta /.snapshots dove ho trovato lo snap e lo snap e visionabile. Il subvol @home - essedo a sè stante - non è stato inserito nello snapshot.
Per fare un lavoro fatto bene, credo serva un subvol come deposito allocato altrove o per lo meno che non s' intenda far gli snapshots e mi sembra anche logico. Sarebbe come depositare un backup dentro il sistema stesso a cui si è fatto il backup, se salta il sistema, addio backup. :P
Sicuramente @e_ale92 e @lele.deb sapran darti info migliori.
A proposito, se segui il wiki di Arch, quando crei una config col comando ''# snapper -c config create-config /path/to/subvolume'', è consigliabile inserire un nome univoco al posto di config, esempio ''# snapper -c radice create-config /'' perché servirà come indicativo sulla config da usare qualora se ne creino molte.

 

[EmanueleC]

Non ho esperienza, btrfs lo uso da poco e non ho ancora creato uno snap quindi non ho l' assoluta certezza. Mi chiedo se sia possibile visionare il contenuto di uno snapshot.

Ovvio, ecco il contenuto del mio snapshot, ovviamente per montarlo ho dovuto aprire Timeshift btrfs, ma tu puoi montarlo all'avvio con le opzioni su fstab, puoi renderlo in sola lettura etc...

 

[EmanueleC]

Aggiungo, per far capire ancora una volta la flessibilità di btrfs, che ti puoi creare un subvol per ogni distro. Ad esempio un subvol per fedora e uno per Ubuntu, è una cosa che non ho mai fatto ma fattibile, e da GRUB decidere quale subvol avviare.
Lo dico perché ho letto di un utente che fa questo.

 

[« MoMy »]

Sì, ho fatto una prova infatti. Così ho pure testato il ''modus operandi''. :P

 

[« MoMy »]

Aggiungo, per far capire ancora una volta la flessibilità di btrfs, che ti puoi creare un subvol per ogni distro. Ad esempio un subvol per fedora e uno per Ubuntu, è una cosa che non ho mai fatto ma fattibile, e da GRUB decidere quale subvol avviare.
Lo dico perché ho letto di un utente che fa questo.

Certo, ragionandoci un po' sopra - se non sbaglio - in /etc/grub.d puoi creare file-config da incorporare al default. Se installo una distro in un subvol a sè stante (che sia o meno nello stesso disco), posso creare per esempio un /etc/grub.d/NUMERO_linux con relativo menuentry ove indicare il subvol radice. In Arch tempo fa c' era il problema simile, c' era /etc/grub.d/10_linux e /etc/grub.d/40_custom con lo stesso menuentry, quindi ti ritrovavi un doppione nel grub. :P

 

[e_ale92]

Non ho esperienza, btrfs lo uso da poco e non ho ancora creato uno snap quindi non ho l' assoluta certezza. Mi chiedo se sia possibile visionare il contenuto di uno snapshot.

EDIT: Ho fatto una prova con snapper.
Al tempo nel Pandino avevo creato la subvol @root e @home. Seguendo il wiki di Arch ho creato la config per la sola @root e lanciato il comando per lo snap.
Il sistema ha creato in / la path nascosta /.snapshots dove ho trovato lo snap e lo snap e visionabile. Il subvol @home - essedo a sè stante - non è stato inserito nello snapshot.
Per fare un lavoro fatto bene, credo serva un subvol come deposito allocato altrove o per lo meno che non s' intenda far gli snapshots e mi sembra anche logico. Sarebbe come depositare un backup dentro il sistema stesso a cui si è fatto il backup, se salta il sistema, addio backup.
Sicuramente @e_ale92 e @lele.deb sapran darti info migliori.
A proposito, se segui il wiki di Arch, quando crei una config col comando ''# snapper -c config create-config /path/to/subvolume'', è consigliabile inserire un nome univoco al posto di config, esempio ''# snapper -c radice create-config /'' perché servirà come indicativo sulla config da usare qualora se ne creino molte.

è quello che la prima volta ho fatto io ahahahah non avevo capito come gestita lo snap, ho brasato / e addio tutto.
il bello di timeshift-btrfs è che gestisce in automatico il mount e l'umount della cartella contenente gli snap. quando lo avvii, monta in rw e quando lo chiudi, smonta. quando snappa in automatico (cron) fa tutto da solo e l'utente non si accorge di nulla.
gestendo in automatico il mount/umount è a prova di nabbo e, unito alla gui, risparmia qualche click e qualche rottura.

continuo a preferire le cose trasparenti (terminale e millemila scritte facili da leggere), ma devo riconoscere la semplicità e la potenza di timeshift-btrfs :sisi:

con snapper, come hai visto tu stesso, bisogna fare moooooolta attenzione alla locazione, altrimenti si corre il rischio di brasare anche i backup :asd:

 

[« MoMy »]

Ricordo infatti che ne parlasti con Lele che avevi brasato e non c' era più lo snap, ma ho voluto provare lo stesso. :P
Tuttavia Snapper, capito il meccanismo - è di una facilità elementare anche se creare un subvol dedicato agli smap non è proprio evidenziato.

 

[e_ale92]

Ricordo infatti che ne parlasti con Lele che avevi brasato e non c' era più lo snap, ma ho voluto provare lo stesso.
Tuttavia Snapper, capito il meccanismo - è di una facilità elementare anche se creare un subvol dedicato agli smap non è proprio evidenziato.

:asd:

ma tu come hai risolto per il mount? cioè, dove crei gli snap?

 

[« MoMy »]

Se per esempio abbiamo i canonici subvol @root e @home, snapper crea la path rispettivamente in / (/.snapshots) e /home (/home/.snapshots) che sarebbero le famose /path/to/subvol. Non fai altro che usarli come punti di mount (in base alle preferenze utente, mount manuale o via /etc/fstab) per i subvol destinati all' archiviazione/menage degli snapshots.
Il problema (se così si può dire) è che le path /.snapshots e /home/.snapshots vengono create nel momento in cui crei uno snapshot e non prima per esempio quando installi o meglio quando crei una config, il che sarebbe più logico, ma credo sia di facile soluzione. :P
In breve, se non monti uno subvol destinato al menage che puntano alle path, gli snap verran depositati nelle path /.snapshots e /home/.snapshots, quindi in caso di problemi, la cosa si fa problematica.
Di default le path vengono create nella path del subvol, se creo una snapshot di @var, in /var troverò /var/.snapshots.
Per dare un senso, uno deve creare subvol per menage in base ai subvol che intende snappare (io snappo, tu snappi egli snappa...e vissero tutti felici snappando :lol:). :P
Almeno, questo è quello che ho capito. ^^

 

[e_ale92]

Se per esempio abbiamo i canonici subvol @root e @home, snapper crea la path rispettivamente in / (/.snapshots) e /home (/home/.snapshots) che sarebbero le famose /path/to/subvol. Non fai altro che usarli come punti di mount (in base alle preferenze utente, mount manuale o via /etc/fstab) per i subvol destinati all' archiviazione/menage degli snapshots.
Il problema (se così si può dire) è che le path /.snapshots e /home/.snapshots vengono create nel momento in cui crei uno snapshot e non prima per esempio quando installi o meglio quando crei una config, il che sarebbe più logico, ma credo sia di facile soluzione.
In breve, se non monti uno subvol destinato al menage che puntano alle path, gli snap verran depositati nelle path /.snapshots e /home/.snapshots, quindi in caso di problemi, la cosa si fa problematica.
Di default le path vengono create nella path del subvol, se creo una snapshot di @var, in /var troverò /var/.snapshots.
Per dare un senso, uno deve creare subvol per menage in base ai subvol che intende snappare (io snappo, tu snappi egli snappa...e vissero tutti felici snappando ).
Almeno, questo è quello che ho capito. ^^

okay, però come fai l'umount del path che contiene gli snap?
io voglio replicare il comportamento di timeshift-btrfs

 

[rebellion]

@« MoMy » @e_ale92 @lele.deb scusassero la butto lì non ho molto approfondito la cosa, ma per evitare di perdere .snapshots non si può specificare nel cron di copiare la cartella in un eventuale storage anche esterno (oppure partizione dedicata)? in caso di piallatura 'involontaria' o totale sCOWness (passatemi il neologismo per evitare di essere volgari una volta di meno..), uno reinstalla la distribuzione e recupera la cartella .snapshots.

 

[« MoMy »]

@e_ale92 Snapper è un tool a linea di comando, tutto il resto va gestito tramite script/service per avere qualcosa di automatico. In più snapper lavora sia con cron o con systemd-timer. Il contro di systemd-timer (mailto a parte che non c'è built-in equivalente di cron) è che devi creare 2 file, un .timer e il .service.
@rebellion Infatti è ciò che bisogna fare, salvare gli snap dove in caso di rottura/incidente/etcetc ci sia la possibilità di accesso. Non serve cron, 'sta cosa la risolvi montando la destinazione dello shot con punto di mount rispettivo al subvol che si intende snappare.

 

[EmanueleC]

allora, cisono due tipi di snapshot con btrfs: atomico e incrementale. Puoi mettere gli snapshot in sola lettura o in lettura e scrittura, montarli o no.

BTRFS has some key capabilities which enable efficient backup solutions:
Instant, Atomic COW Snapshots
Since the snapshots are atomic, when a snapshot is restored it appears to applications as if a power loss had occurred (and the filesystem has gone back to an earlier state). Thus it is possible to backup databases without stopping them beforehand.
Incremental Snapshot Transfer
Efficiently determining and streaming the differences between two snapshots if they are either snapshots of the same underlying subvolume, or have a parent-child relationship. This is far quicker than e.g. rsync could, especially on large file systems. (For instance, rsync cannot be aware of mere metadata changes like filename, location etc but the FS itself is certainly aware of it.)

Nel caso si fa incrementale, si può mettere un intero snapshot su un disco diverso.

https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

 

[e_ale92]

@« MoMy » @e_ale92 @lele.deb scusassero la butto lì non ho molto approfondito la cosa, ma per evitare di perdere .snapshots non si può specificare nel cron di copiare la cartella in un eventuale storage anche esterno (oppure partizione dedicata)? in caso di piallatura 'involontaria' o totale sCOWness (passatemi il neologismo per evitare di essere volgari una volta di meno..), uno reinstalla la distribuzione e recupera la cartella .snapshots.

sì, ma su un portatile non sempre si ha un "posto esterno" su cui salvare e timeshift-btrfs risolve la cosa smontando la cartella alla chiusura, in automatico

@e_ale92 Snapper è un tool a linea di comando, tutto il resto va gestito tramite script/service per avere qualcosa di automatico. In più snapper lavora sia con cron o con systemd-timer. Il contro di systemd-timer (mailto a parte che non c'è built-in equivalente di cron) è che devi creare 2 file, un .timer e il .service.
@rebellion Infatti è ciò che bisogna fare, salvare gli snap dove in caso di rottura/incidente/etcetc ci sia la possibilità di accesso. Non serve cron, 'sta cosa la risolvi montando la destinazione dello shot con punto di mount rispettivo al subvol che si intende snappare.

sisi so che va fatto a mano, volevo sapere proprio come avevi fatto, nel senso, che path hai specificato per il backup e come lo smonti? se è ~/.snapshots come fai a smontare la cartella? mi sfugge la cosa u.u

cioè, script, a mano o in automatico, non mi importa. volevo proprio sapere come fare xD