Newsgroup: it.comp.os.linux.iniziare
Titolo: Come partizionare un disco fisso nel 2017

Sono su Debian jessie e devo partizionare un disco fisso, da 2 tera, per
poi installarci la nuova stabile stretch.
 
Faro' 14 partizioni, delle quali 1 per lo swap [*] e 1 per l'estesa DOS,
dunque 12 utili in totale.
 
Ringrazio in anticipo chi mi puo' dare consigli o info sui seguenti due
modi da seguire, o su eventuali altri.
 
1. Dalla jessi in console a caratteri do fdisk e partiziono. Lo conosco
a memoria e gia' da un po' di anni lui sceglie automagicamente il punto
giusto dove iniziare ogni partizione.
Quindi avvio da dvd_1 e inizio l'installazione, facendogli trovare le
partizioni gia' fatte (e con disco che ora il BIOS vede).
 
2. Avvio da dvd_1, scelgo "a mano" e partiziono con l'orologio svizzero
(che non ricordo piu' come si chiama) dall'installer.
Quindi esco per poi riavviare una seconda volta l'installazione e fargli
trovare le partizioni che lui stesso aveva fatto prima.
 
---------
[*] Non usando MAI e poi mai suspend o cose simili, secomdo voi 2 giga
di swap sono: troppi, pochi, giusti?
 
 
-- 
bye, Yoda
 


e smettila di crosspostare su icoli e icols.
 
Ciao Jack

 e smettila di crosspostare su icoli e icols.
 
Mi son dimenticato d'avvisare; e chiedo scusa.
Ma il male sarebbe al piu' che non metto il f/u su icol.sys o icoli.
 
Pero' gia' da molti anni penso che non s'usi piu', visto che ad esempio
Leonardo S., che un tempo era il primo a protestare, ora crossposta in
continuazione anche lui -- ciao!
 
 
-- 
bye, Yoda
 

 dunque 12 utili in totale.
 
... 14 partizioni? Praticamente fai una partizione per directory che si trova
sulla root?
 
Enrico
P.S. usa LVM

 voi 2 giga di swap sono: troppi, pochi, giusti?
 
Quanta RAM hai?
 
 
PS.
Ho impostato il followup-to verso icol.iniziare mantenendo
il crosspost anche si icol.sys.
Quando apri un topic va bene postare su più gruppi, ma è poi
meglio valutare il ng più adeguato tipo icol.iniziare e
impostare il followup-to solo verso quello:
http://faq.news.nic.it/wiki/ItNewsAiutoBase#xpost
 

On 26/06/2017 13:38, Yoda wrote:
 
Potresti però anche non fare sempre crossposting.
 
bye
 
 
-- 
"Non esiste alcun dio, ma non ditelo al mio domestico,
se no di notte viene ad uccidermi."  - Voltaire

 testing se l'uso è desktop.
 
Usi/hai usato la testing e quindi scrivi a ragion veduta o stai solo
scrivendo la tua opinione per sentito dire?
 
 


In premessa ho consigliato all'OP di aspettare altre
risposte, proprio perchè non sono un utente abituale
Debian, mi pare di aver letto in passato che per utilizzo
"non server" quindi anche desktop testing potrebbe essere
una scelta da considerare per via del software più recente
che mette a disposizione.
Tuttavia, mi dirai, ci sono i backports e se ti serve
qualcosa di nuovo che il repo stable non contiene puoi
sempre servirti lì.
 
Quindi se ti pare comunque meglio usare una stable, magari
perchè usi Debian abitualmente e la consoci meglio di me,
consiglia pure in tal senso l'OP...

 Quanta RAM hai?
 
4 giga.
 
-- 
bye, Yoda
 

 Potresti però anche non fare sempre crossposting.
 
Si' scusa ho dimenticato di dirlo e di metterci o chiedere il f/u,
mi spiace -- ciao
 
-- 
bye, Yoda
 

 P.S. usa LVM
 
Geazie, ma lo odio.. non capisco che problema possa esserci a montare
una partizione in una subdirectory, ad esempio /home/video/film/wes per
tutti i film wastern che colleziono.
E' tutto molto piu' facile anche da catalogare, oltre che da mantenere,
in uno script per root:
 
updatedb -l 0 --prunepaths "$TOGLI" -o /home/bin/db/$NOME -U $1
 
con:
TOGLI="$2" (in questo caso vuoto, ma --prunepaths "" ci vuole sempre)
NOME="$(basename $1)"
$1 = /home/video/film/wes
 
 
-- 
bye, Yoda
 

 tutti i film wastern che colleziono.
 
Ci ho pensato un po', ma onestamente non trovo motivi validi per 
spezzare i dati in diverse partizioni invece di usare normali directory.
Vedo solo svantaggi, soprattutto se sono sullo stesso disco.
 
Mi puoi chiarire l'utilita`? :)
 
Grazie.
Bye.
 

 consiglia pure in tal senso l'OP...
 
Grazie ma l'OP, che sarei io, probabilmente ce le mette entrambe.
E' una scelta che feci l'anno scorso di NON mettere stable ma jessie,
cosi' adesso son rinasto con la jessie=oldstable.
 
Con hardware vecchio non sempre l'upgrade va meglio, ora la nuova
stabile penso che la preferiro', come distro principale. La metto
soprattutto perche' parte /gia'/ con systemd & C., qui invece ci
sono ancora ruderi del sysV -- ciao!
 
Aggiungo una curiosita': anche l'anno scorso pensavo che la wheezy
potesse essere piu' adatta all'hardware vecchio, invece la jessie e'
andata benissimo.. mi sa che anche quest'anno mi finira' cosi'!
 
-- 
bye, Yoda
 

>>>>  
http://www.bb2002.it
 :)  <<<<<
........... [ al lavoro ] ...........

 consiglia pure in tal senso l'OP...
 
Naaah! a dispetto delle apparenze momentanee, non penso assolutamente
che Yoda necessiti di consigli per installare una Debian come piace a
lui ... credo che tergiversi solo un po' perche ` sa che se si vuole la
garanzia di successo, con la Debian e` meglio non essere precipitosi ma
invece perdere un po' di tempo informandosi, leggendo le release notes,
ecc.
 
https://www.debian.org/releases/stable/amd64/release-notes/
 
 
in modo che poi l'installazione va a buon fine e si possa dire: potevo
evitare di leggermi tutta quella roba .. e` andata su da sola! :-)
 
 
 

 mette nelle sue macchine multifunzione
 
Ma Linux (Debian) oltre la 14-ma non le vede, cosi' almeno era fino a
qualche anno fa.. hanno cambiato?
 
-- 
bye, Yoda
 

Addi' 26 giu 2017, Alessandro Pellizzari scrive:

Non capisco con "spezzare i dati" cosa vuoi dire.
Da me ogni subdirectory puo' essere:
- una ordinaria subdir della sua dir-padre (o madre?);
- una subdir dove ci innesto una nuova partizione.
 
Ad esempio in /mnt ho:
/mnt/c1
/mnt/c2
/mnt/c3
/mnt/c4
/mnt/loop
/mnt/macchine
/mnt/ojessie
/mnt/wheezy
 
- In cX ci monto le rispettive 4 partizioni del disco usb, quando lo
devo usare.
- In macchine c'e' montata la partizione per le macchine virtuali.
- Le due ojessie e wheezy sono semplicemente le partizioni sullo sdb
(qui sono sullo sda) che hanno ancora roba.. mi puo' sempre servire.
 
Altro esempio. In /home ho /home/video/, in ogni subdir della quale c'e'
montata una partizione: di sda o sdb, dove /c'erano gia'/ dei film o ce
li metto tutt'ora.
 
Ancora: ad esempio adesso copio "cp --attributes-only" il ramo film
nella nuova /home ed allora e' un momento avere tutto montato.. chi
lo sa cosa tutto dovrei invece fare con LVM - figurati!
 
Insomma: Cosa me ne potrei fare del LVM, a me nel caso puo' servire di
piu' sapere, se sposto o copio dati grossi, che origine e destinazione
stanno su dischi diversi.
 
Grazie e ciao -- fammi sapere cosa ne pensi!
 
-- 
bye, Yoda
 

 evitare di leggermi tutta quella roba .. e` andata su da sola! :-)
 
-- 
bye, Yoda
 

 li metto tutt'ora.
 
Ah, ok, mi mancava questo dettaglio.
 
Pensavo dividessi i film in diverse partizioni invece che in cartelle 
solo per categorizzarli meglio, e non capivo il senso.
Soprattutto coi film che occupano centinaia di MB, per cui puoi trovarti 
con un disco con 1GB libero e non potermi mettere niente. :)
 
Bye.

> Mi puoi chiarire l'utilita`? :)
 
Vedi, c'e' anche un fatto che dimenticavo. Per alcuni dati, esempio
un film raro o una buona parte delle foto in /home/video/foto/, ho il
backup che faccio sul disco diverso da quello dove stanno gli originali,
altrimenti sarebbe inutile.
Ebbene, LVM non credo (ma non lo conosco neanche un po' eh) che potrebbe
agevolarmi in questo, perche' per me e' cosa immediata farlo - ariciao!
 
-- 
bye, Yoda
 

 con un disco con 1GB libero e non potermi mettere niente. :)
 
I cortometraggi con John Wayne, meno di un'ora e in B/N, ci stanno
abbondanti pur avendo un segnale ottimo (si fa per dire):
701 il_sentiero_solitario-1936.avi
688 il_re_dei_pecos-1937.avi
;^)
 
Certo non ci sta Troy in HD Director's Cut. Comprai il dvd in illo
tempore: 'na schifezza di film!
Poi pero' in rete vidi la Director's cut.. ebbene: e' un altro film!
 
Idem per "Le Crociate": un abisso tra le due versioni!
Appena in po' meglio invece quella di Avatar, che non capisco per qual
buon motivo abbiano poi deciso di tagliarla.
 
-- 
bye, Yoda
 

 
 
nonzo... appena mi rientra una toshiba da smantellare guardo il disco e 
riferisco (rima baciata)



Teoricamente non dovrebbero esserci limiti da parte dell'OS.
Però poi bisognerebbe provare in pratica.
Occhio ai colli di bottiglia, esempio campato per aria e
inventato al volo:
poniamo che fdisk sia limitato alla creazione di non più di 20
partizioni logiche... In quel caso il problema non sta in linux
in generale ma nel software fdisk. Quindi se vuoi fare una prova
pratica informati sulle eventuali limitazioni dei vari softwares
coinvolti. Come oh detto è solo un esempio campato per aria, non
so se fdisk abbia limitazioni in tal senso...
 
La domanda è interessante, cioè, per quel che riguarda le mie
esigenze pratiche no, ma a livello di conoscenza ci sta. Come
osservavi nel tempo le limitazioni sono cambiate e se ne trova
conferma anche nel link seguante:
 
https://unix.stackexchange.com/questions/33555/what-is-the-max-partition-supported-in-linux
 
-----
There are two limits. On is the support in Linux, the other is the
maximum count in the used partition table scheme: It depends if you use
the legacy MBR or the newer GPT .
 
MBR supports four primary partition. One of them could be a extend
partition which can contain an arbitrary number of logical partitions
limited only by your disk space.
 
GPT supports up to 128 "primary" partitions.
 
In the old days, Linux supported only up to 63 partitions on IDE and 15
on SCSI disks because of limited device numbers. Today the kernel can
allocate device numbers dynamically (udev is the keyword) so this limits
should not be longer valid.
-----
 
Detto questo non capisco perchè avere tutte quelle partizioni,
sì che parliamo di un disco da 2TB però di 15 partizioni per
uso desktop casalingo non ne vedo la necessità... Poi va bè, io
sarò all'altro estremo visto che metto tutto nella root, ma
una volta che hai separato eventualmente la /home, non mi pare
ci sia moltro altro da spezzettare.

 ci sia moltro altro da spezzettare.
 
Ma senti, adesso passo alla stretch su un nuovo disco. La mia home
attuale NON la copio ne' la monto, perche' tutto quello (dati foto
pdf..) che voglio avere sta ognuno su una directory dedicata. Tali
directory sono semplicemente da montare dove voglio.
 
In altre parole, per avere ad esempio tutte le foto 2010-2016 mi basta
aggiungere la riga per montarle in /etc/fstab. Questo perche' esse
stanno tutte in una certa partizione a loro dedicata di uno dei dischi
miei, (attualmente amcora le monto in /home/video/foto/2010-2016/).
 
Con l'installazione devo stare molto attendo, perche' i NUMERI dell'user
e dei group non sempre sono gli stessi. Ad esempio, montando una Slack
(morta) sulla Deb mi posso trovare la home di yoda che appatiene.. al
gruppo fax.
 
-- 
bye, Yoda
 

 qualche anno fa.. hanno cambiato?
 
No. Il problema non è né Linux né fdisk, ma il fatto che MBR ha delle
limitazioni. Se usi GPT queste limitazioni le superi, altrimenti se vuoi
mantenere MBR devi usare LVM
 
Enrico

 poi installarci la nuova stabile stretch.
 
Ti hanno già abbondantemente risposto, dal canto mio non rinuncio più a 
LVM nemmeno sotto tortura. In ambiente virtuale il vantaggio più 
visibile è che aggiungendo un disco fisico, fai l'extend a caldo (della 
serie watch -n "df -h" e vedi aumentare lo spazio libero). Ma il 
vantaggio di LVM lo apprezzi comunque ovunque, seppur in maniera meno 
evidente.
 

 LVM nemmeno sotto tortura
 
Pensa che io ho quasi abbandonato LVM in favore di ZFS, e personalmente
spero che prima o poi Btrfs divenga usabile ;)
 
Enrico

Addi' 30 giu 2017, writethem scrive:

Non posso esprimere un giudizio su LVM che non conosco, ma son convinto
che non puo' semplificarmi la situazione che ora ti descrivo con un
esempio.
Attualmente ho due dischi fissi sda e sdb, piu' un disco usb per backup,
montato in /mnt/usb.
 
Ecco lo scenario.
- Sono con la jessie nel disco sda, in /home ho creato la directory video
e in essa le due subdirectory cam foto.
- Monto sdb7 in /home/video/foto, sda10 in /home/video/cam.
- Lo shutdown lo do come root sempre e solo da console con uno script
per fare il backup delle directory che mi interessano, cosi':
.....
rsync -v -a --delete /home/video/foto /mnt/usb/home/video/
.....
shutdown -h now
 
Ebbene, dimmi come puo' mai semplicifarsi questa situazione elementare.
 
 
-- 
bye, Yoda
 

 Ebbene, dimmi come puo' mai semplicifarsi questa situazione elementare.
 
Nell'immediato non hai vantaggi, ma se un domani devi aggiungere un 
disco, con lvm fai un'extend dei volumi mantenendo la situazione 
invariata e aggiungendo lo spazio che ritieni necessario, anche a caldo 
o da un raid che gestisca la cosa ad un layer inferiore.
 
In ambito desktop mi rendo conto possa essere un po' sovradimensionato, 
ma del resto hai xpostato anche su icols, quindi ti becchi anche questa 
risposta :-)
 
 
 
 
 


Vero, ma io quando approfondii mi fermai per l'assenza di integrazione 
nativa nel kernel a causa delle licenze di solaris. E tanto mi bastò per 
continuare a giocare con lvm. Magari ora le cose sono cambiate, non saprei.

 Ebbene, dimmi come puo' mai semplicifarsi questa situazione elementare.
 
Ad esempio, puoi  usare gli snapshot per fare i backup. Tra l'altro, nessuno
ti impedisce di fare due LV in mirror o di mettere un LV su di un PV ed uno
su di un altro
 
Enrico

 Magari ora le cose sono cambiate, non saprei.
 
La situazione di ZFS è "all'incirca":
 
 - Su CentOS/RHEL/Fedora hai un repository dedicato, da aggiungere
   successivamente e che permette la gestione del modulo via DKMS.
 - Su Debian hai i pacchetti (in non-freeAHAHAHAHAH).
 - Su Ubuntu lo hai pacchettizzato nel kernel.
 
Per Debian e Ubuntu ci sono inoltre guide su come usarlo per /, personalmente
lo uso con CentOS e il repository dedicato (se non uso FreeBSD)
 
Enrico

Addi' 30 giu 2017, writethem scrive:
 

Capisco se uno usa il pc fare cose, allora probabilmente puo' essere
schiacciante la superiorita' di LVM; ma io faccio cose per usare il pc.
 
Oh Dio adesso non sarebbe facile, anzi oramai e' impensabile tornare a
- classificatori (scatole apposite) per le diapositive;
- proiettore;
- schermo perlinato,
dunque in questo senso posso dire di usare il pc anche per fare cose.
 
Pero' siamo (sono io) sempre nel campo hobby e se devo aggiungere foto
che non ci stanno piu', semplicemente creo una foto2/ (o una subdir di
foto/) dove ci monto una nuova partizione.
 
Comunque, adesso che m'hai detto del fatto che LVM da' nuovo spazio ad
ogni partizione sotto il suo controllo, riconosco che e' veramente una
cosa utilissima, puo' diventare una comodita' irrinunciabile anche per
un desktop (e addirittura fondamentale per un utente poco esperto).
 
-- 
bye, Yoda
 

 un desktop (e addirittura fondamentale per un utente poco esperto).
 
Per farti capire meglio:
 
[root@localhost ~]# fdisk -l /dev/sd[bc] |grep Disk
Disk /dev/sdb: 8589 MB, 
8589934592
 bytes, 16777216 sectors
Disk /dev/sdc: 17.2 GB, 
17179869184
 bytes, 33554432 sectors
[root@localhost ~]# pvcreate /dev/sd[bc]1
  Physical volume "/dev/sdb1" successfully created.
  Physical volume "/dev/sdc1" successfully created.
[root@localhost ~]# vgcreate test /dev/sdb1
  Volume group "test" successfully created
[root@localhost ~]# vgs test
  VG   #PV #LV #SN Attr   VSize VFree
  test   1   0   0 wz--n- 8.00g 8.00g
[root@localhost ~]# lvcreate -n data -l +100%FREE test
  Logical volume "data" created.
[root@localhost ~]# lvs test
  LV   VG   Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data test -wi-a----- 8.00g                                                    
[root@localhost ~]# mkfs.ext4 /dev/test/data 
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
524288 inodes, 2096128 blocks
104806 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=
2147483648
 
64 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
 
Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
 
[root@localhost ~]# mount /dev/test/data /mnt/
[root@localhost ~]# df -h /mnt/
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/test-data  7.8G   36M  7.3G   1% /mnt
[root@localhost ~]# vgextend test /dev/sdc1 
  Volume group "test" successfully extended
[root@localhost ~]# vgs test
  VG   #PV #LV #SN Attr   VSize  VFree 
  test   2   1   0 wz--n- 23.99g 16.00g
[root@localhost ~]# lvs test
  LV   VG   Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data test -wi-ao---- 8.00g                                                    
[root@localhost ~]# lvresize -l +100%FREE test/data
  Size of logical volume test/data changed from 8.00 GiB (2047 extents) to 23.99 GiB (6142 extents).
  Logical volume test/data successfully resized.
[root@localhost ~]# lvs test
  LV   VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data test -wi-ao---- 23.99g                                                    
[root@localhost ~]# df -h /mnt/
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/test-data  7.8G   36M  7.3G   1% /mnt
[root@localhost ~]# resize2fs /dev/test/data 
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/test/data is mounted on /mnt; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 3
The filesystem on /dev/test/data is now 6289408 blocks long.
 
[root@localhost ~]# df -h /mnt/
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/test-data   24G   44M   23G   1% /mnt
[root@localhost ~]#
 
Ovviamente puoi fare anche giochetti carini tipo che il LV si trova solo su di
un PV (disco), o che il LV sia in mirror, o che il LV sia posto sotto snapshot
(quest'ultima è molto comoda durante il backup); e ovviamente ci sono dei
"limiti" che conviene sempre tenere a mente (e.g. quando espandi un LV questo
potrebbe risultare frammentato, problema che si mette comunque a posto sempre
tramite gli appositi comandi e che non crea alcun disservizio al sistema)
 
Enrico

> Ad esempio, puoi  usare gli snapshot per fare i backup. 
 
Hai fatto piangere i gattini!!
 
(che poi lo fanno tutti e' un altra cosa).
 
Giulia
 
 

 Hai fatto piangere i gattini!!
 
In effetti per come l'ho scritta, i gattini si stanno sparando ^__^;
 
Quello che intendevo è il solito giro che SI DOVREBBE FARE con LVM:
 
 - Creo lo snapshot;
 - Monto lo snapshot;
 - Faccio il backup dei file nello snapshot;
 - Smonto lo snapshot;
 - Distruggo lo snapshot.
 
C'è comunque da dire che su ZFS, grazie anche a COW,  gli snapshot funzionano,
ovvero puoi fare quanti snapshot vuoi senza influire sulla stabilità del
sistema. Addirittura, puoi archiviare uno snapshot su file e/o inviarlo via
rete, per poi ripristinarlo anche su di un altro pool (in teoria anche su
Btrfs dovrebbe funzionare uguale, ma non avendolo mai usato per ovvi motivi
non posso confermarlo)
 
Enrico

 crea alcun disservizio al sistema)
 
Be' a tutto questo ci penserei in seguito.. si' lo so che adesso si
mette tutto il backup in rete, a prescindere da LVM, ma a me non va,
ci capisco troppo poco di reti -- ciao!
 
-- 
bye, Yoda
 

 Enrico
 
Si funziona anche su btrf, sia inviando gli snapshot su filesystem locali 
che remoti (nel mio caso, vedi sotto, sono bel oltre i 100).
 
 
Attenzione, mi risulta che gli snapshot siano atomici a livello di singolo 
file (quindi il file ha un preciso stato di modifica), ma non per i vari 
file (quindi in un database ci si puo' trovare con un file in un certo 
momento di modifica e altri in altri momenti).
 
 
 
Snapshot list in ' /dev/sda3 ' device
. . . btrfsreceive/root/root-2016-08-28-12-35-01.1
. . . btrfsreceive/root/root-2016-08-31-16-42-01.2
        ...........
        ...........
. . . btrfsreceive/root/root-2017-06-10_13:47:01.103
. . . btrfsreceive/root/root-2017-06-10_15:20:01.104
 

 momento di modifica e altri in altri momenti).
 
I backup a suon di snapshot si possono fare solo se tutto e' atomico, dal servizio/i che girano sul server
al filesystem a lvm.
 
Per capirci li farei tranquillamente se installo prodotti "commerciali" (Joomla,asterisk,openoffice  ecc ecc),
ma mai il gestionale pinco pallino che non so come gestisce internamente le transazioni e i commit,
e se si tiene dei pezzi in memoria e li scrive in ritardo per ragioni sue interne ?
In quel caso devi seguire le istruzioni di chi produce quel software per il backup non puoi snapshottare
e sperare che funzioni tutto.
 
Giulia
 

 Giulia
 
:)
 
Concordo, e' necessaria una attenta valutazione.
 
Personalmente parto dal tipo di rischio che sono disposto a sopportare in 
caso di mancanza di corrente, crash del sistema, ecc., e dagli eventuali 
metodi di riduzione del rischio (per il esempio il classico dump dei dati).
 
Poi lo snapshot viene di conseguenza e piuttosto facile (se sono in grado di 
recuperare da un crash di sistema sono in grado anche di recuperare da un 
restore di uno snapshot).
 
In aggiunta, valutando bene e facendo varie prove, si possono mantenere un 
buon numero di snapshot, che insieme alle valutazioni di cui sopra fanno 
diventare parecchio basse le probabilita' di fallire con il recupero.
 
E un numero elevato di snapshot rendono anche disponibile un grezzo archivio 
storico rapidamente accessibile.
 
 
Sempre tenendo a mente che lo snapshot non e' un backup, il raid non e' un 
backup, in un certo senso nemmeno il backup è un backup, il backup e' il 
restore.
 

 ci capisco troppo poco di reti -- ciao!
 
Non capisco cosa c'entri la rete con tutto questo, ma va beh
 
Enrico

 partizioni gia' fatte (e con disco che ora il BIOS vede).
 
Mi autorispondo parzialmente: Tutto OK, ma farlo con gdisk anziche'
fdisk, cioe' usare GPT al posto di MBR.
 
-- 
bye, Yoda
 


Visto che t'avevo accennato a gdisk in luogo di fdisk per
passare da MBR a GPT, ti riporto il mio partizionamento
del disco di sistema precisando che si tratta di un PC
con vecchio BIOS standard, no UEFI quindi.
 
-----------------
gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.0
 
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
 
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 488397168 sectors, 232.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A186F4CZ-5GDF-4693-BD87-F692431FE2D3
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
 
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            4095   1024.0 KiB  EF02  BIOS boot partition
   2            4096          413695   200.0 MiB   EF00  EFI System
   3          413696       210128895   100.0 GiB   8300  Linux filesystem
   4       210128896       480112639   128.7 GiB   8300  Linux filesystem
   5       480112640       488397134   4.0 GiB     8200  Linux swap
---------------------
 
La prima partizione serve a GRUB 2.
La seconda servirà forse se mai sposterò l'SSD su un PC più recente
che supporta UEFI invece del classico BIOS, per il momento è inutilizzata
ma visto che sono solo 200 MB, meglio predisporla già da subito.
Il resto sono due partizioni linux, una per la root e l'altra per
stoccaggio dati ad acesso rapido, da montare alla bisogna. Infine
lo swap, pari ai 4GB della RAM di sistema.
 
Ciao!  :)