Il 05/03/2023 18:34, pinguino ha scritto:
Io metterei 3 dischi SATA meccanici da 500GB in configurazione tipo
RAID1. Per avere sempre 3 copie identiche del sistema e della
partizione della Home. In tutto occupano circa 50Gb, poi per il resto
si può usare per la cache (lvm) anche se non so come si fa.
Io avevo creato delle aree di SWAP sui dischi. Possono servire ?
quindi i dischi verrebbero usati per fare i backup.
cancella la nota sulla cache lvm (avevo capito che i dischi da 500 erano ulteriori dati).
se hai i tre computer nello stesso pc e ti va in corto l'alimentatore sparando 200V nell'intera macchina? addio a tutte le copie.
opzione 1:
piglia 3 dischi esterni (USB) e fai i backup alternando attentamente i dischi: la probabililta' che tre dischi su tre siano guasti e'
decisamente zero. Finita la copia, mettili in un cassetto chiusi a
chiave. Niente raid1, non e' applicabile. uno script in bash ti
organizzi i backup per date e vivi sereno.
opzioni 2:
anziche' 500 sali a 1tb ma solo due dischi. Ovviamente vanno alternati sempre. devi avere sempre la garanzia di avere copie alternate.
Per entrambe le soluzioni, su ogni disco hai modo di mettere piu' copie suddivise per date (ripeto: uno script bash con rsync e puoi vivere serenamente).
come un disco da' problemi, sostituiscilo (i prodotti attuali sono affidabili, ma fidarsi e' bene, non fidarsi e' meglio). Dopo qualche
anno cambiali.
terza soluzione: acquisti uno spazio in cloud (mi viene in mente drive
di google, ma ce ne sono tanti) e ci scarichi il backup periodicamente (qualsiasi cosa ti succede in casa hai le copie disponibili altrove).
Anche in questo caso, piu' copie sempre.
M.
Le cartelle fondamentali da salvare sono /etc /home e /root (la configurazione della macchina e i dati utente e eventuali dati di root se accedi spesso con quell'utente).
rsync error: some files/attrs were not transferred (see previous
errors) (code 23) at main.c(1333) [sender=3.2.3]
Il 16/04/2023 15:31, pinguino ha scritto:
rsync error: some files/attrs were not transferred (see previous
errors) (code 23) at main.c(1333) [sender=3.2.3]
alcuni file non era piu' presenti tra la prima fase di analisi e la
copia effettiva, altri file erano bloccati.
Visto che hai accennato a /proc, tieni presente che quella non e' una directory come tutte le altre, ma la rappresentazione delle variabili
interne del kernel per renderle utilizzabili facendole apparire come se
fosse il normale filesystems.
lo stesso vale per /sys, per /run e per svariate altre cose. Totalmente inutile copiarle.
cerca on line "linux filesystems" e troverai in un mare di indicazioni.
la prima che ho trovato: https://www.linuxfoundation.org/blog/blog/classic-sysadmin-the-linux-filesystem-explained
Le cartelle fondamentali da salvare sono /etc /home e /root (la configurazione della macchina e i dati utente e eventuali dati di root
se accedi spesso con quell'utente).
le altre sono in qualche modo sacrificabili, le puoi reinstallare quando
vuoi e non ha granche' senso salvarle anche perche' in caso di disastro,
fai prima ad reinstallare e poi a ripristinare i tuoi dati.
al massimo, pigliati l'elenco dei pacchetti installati (dpkg -l >
lista.txt, oppure "apt list --installed" >lista.txt) in modo da poterli ripristinare in caso di bisogno. Resto dell'avviso che i dati di configurazione e le home utente sono fondamentali, il resto e'
recuperabile per altre vie. Salveresti roba inutile che tra l'altro
varia in base agli aggiornamenti.
Mauro.
Anche /var e /opt possono avere file solo locali.
On Sun, 16 Apr 2023, mauro morichi wrote:
Le cartelle fondamentali da salvare sono /etc /home e /root (la
configurazione della macchina e i dati utente e eventuali dati di root
se accedi spesso con quell'utente).
--
Leonardo Boselli
Firenze, Toscana, Europa
http://i.trail.it
tel:+393287329225
Quindi conviene copiare solo la /etc/ e la /root , per copiare il
sistema ?
Tranne il file fstab, perché da me sono diversi i numeri degli ID
delle partizioni.
Il 16/04/2023 17:50, pinguino ha scritto:
Quindi conviene copiare solo la /etc/ e la /root , per copiare il
sistema ?
Tranne il file fstab, perché da me sono diversi i numeri degli ID
delle partizioni.
no.
la etc contiene la configurazione del sistema. Aggiungi per sicurezza
/opt e /var. Root non serve al sistema, e' un utente.
fstab e' legato alla macchina (gli uuid sono sempre diversi). Ma in caso
di mancanza non e' cosi' complicato crearne uno nuovo.
Con questo hai salvato i tuoi dati e la via per ripristinare un sistema andato. Quello che intendi tu e' forse l'immagine del sistema.
Il 16/04/23 18:47, mauro morichi ha scritto:Buon giorno Lista,
Il 16/04/2023 17:50, pinguino ha scritto:
Quindi conviene copiare solo la /etc/ e la /root , per copiare il
sistema ?
Tranne il file fstab, perché da me sono diversi i numeri degli ID
delle partizioni.
no.
la etc contiene la configurazione del sistema. Aggiungi per sicurezza
/opt e /var. Root non serve al sistema, e' un utente.
fstab e' legato alla macchina (gli uuid sono sempre diversi). Ma in
caso di mancanza non e' cosi' complicato crearne uno nuovo.
Con questo hai salvato i tuoi dati e la via per ripristinare un
sistema andato. Quello che intendi tu e' forse l'immagine del sistema.
Buon giorno Lista,
Ok. Allora faccio due script.
Uno che fa la copia degli utenti. Cioè quelli della /home/ e /root/
L'altro che copia le cartelle del sistema:Queste le ho provate una ad una, e funzionano tutte, tranne la sys.
/bin/ /etc/ /opt/ /var/ /dev/ /lib/ /lib32/ /lib64/ /libx32/ /sbin/
/srv/ /sys/ /usr/
Visto che sono poche faccio una riga di script, per ogni cartella.
Così gestisco meglio anche le eventuali esclusioni.
La prima volta, con il nuovo PC, ho usato clonezilla per copiare tutto
il disco. E' stato velocissimo. Viaggiava a circa 15 GB. Ma quello copia tutto. Poi ho dovuto cambiare alcuni UUID ed il file di fstab e di grub. Perché all'avvio nel menu si confondeva e non partivano bene i due sistemi. Sicuramente rsync, quando è configurato bene è più veloce e funzionale. Per fare un'immagine del sistema anni fa avevo usato remastersys ed
un'altro software di cui ora non ricordo il nome ora. Funzionavano bene, facevano una immagine che stava in un dvd da 4 Giga. Poi hanno iniziato
ad avere dei problemi e davano degli errori. Allora non li ho più usati. Sono passato a clonezilla.
Grazie
Saluti
Claudio
L'altro che copia le cartelle del sistema:Queste le ho provate una ad una, e funzionano tutte, tranne la sys.
/bin/ /etc/ /opt/ /var/ /dev/ /lib/ /lib32/ /lib64/ /libx32/ /sbin/
/srv/ /sys/ /usr/
Mi da un sacco di errori e poi blocca tutto il sistema tutto il PC.
Devo riavviare, con reset hardware. E' normale questo ?
Anche la sys è una dir da non toccare ?
Il 17/04/2023 10:52, pinguino ha scritto:
L'altro che copia le cartelle del sistema:Queste le ho provate una ad una, e funzionano tutte, tranne la sys.
/bin/ /etc/ /opt/ /var/ /dev/ /lib/ /lib32/ /lib64/ /libx32/ /sbin/
/srv/ /sys/ /usr/
Mi da un sacco di errori e poi blocca tutto il sistema tutto il PC.
Devo riavviare, con reset hardware. E' normale questo ?
Anche la sys è una dir da non toccare ?
/dev
/run
/proc
/sys
Si salva un po' la dev, ma pure lei ha i device generati on the fly
quindi e' quasi inutile salvarli.
Il 17/04/23 13:00, mauro morichi ha scritto:
Il 17/04/2023 10:52, pinguino ha scritto:
L'altro che copia le cartelle del sistema:Queste le ho provate una ad una, e funzionano tutte, tranne la sys.
/bin/ /etc/ /opt/ /var/ /dev/ /lib/ /lib32/ /lib64/ /libx32/ /sbin/
/srv/ /sys/ /usr/
Mi da un sacco di errori e poi blocca tutto il sistema tutto il PC.
Devo riavviare, con reset hardware. E' normale questo ?
Anche la sys è una dir da non toccare ?
/dev
/run
/proc
/sys
Si salva un po' la dev, ma pure lei ha i device generati on the fly
quindi e' quasi inutile salvarli.
Buon giorno Lista,
Ok, Ho tolto le cartelle di cui sopra.
Ed ho anche aggiunto la cartella /boot/grub/ con l'esclusione di
questo grub.cfg.
Ci sono altri files che contengono i dati del menu di grub per l'avvio iniziale ?
Grazie
Saluti
Claudio
Dovrebbero essere tutte lì... Comunque senza stare ad impazzire a
trovare quali dir backuppare io normalmente faccio un backup per ogni filesystem (fs) e uso l'opzione -x di rsync. Con quell'opzione non fai
il backup delle subdir in cui è montato un altro fs quindi ad esempio
quando fai un rsync di / esclude tutti i vari /proc, /sys, ... che già
hai citato e ad esempio ti esclude anche eventuali usb drive che sono
montati da qualche parte tipicamente sotto /mnt.
partizione diversa per le homes o /var etc... poi devi fare un rync per ognuna delle tue partizioni in fstab
Piviul
On 4/18/23 09:25, pinguino wrote:
Il 17/04/23 13:00, mauro morichi ha scritto:
Il 17/04/2023 10:52, pinguino ha scritto:
L'altro che copia le cartelle del sistema:Queste le ho provate una ad una, e funzionano tutte, tranne la sys.
/bin/ /etc/ /opt/ /var/ /dev/ /lib/ /lib32/ /lib64/ /libx32/ /sbin/
/srv/ /sys/ /usr/
Mi da un sacco di errori e poi blocca tutto il sistema tutto il PC.
Devo riavviare, con reset hardware. E' normale questo ?
Anche la sys è una dir da non toccare ?
/dev
/run
/proc
/sys
Si salva un po' la dev, ma pure lei ha i device generati on the fly
quindi e' quasi inutile salvarli.
Buon giorno Lista,
Ok, Ho tolto le cartelle di cui sopra.
Ed ho anche aggiunto la cartella /boot/grub/ con l'esclusione di
questo grub.cfg.
Ci sono altri files che contengono i dati del menu di grub per l'avvio
iniziale ?
Grazie
Saluti
Claudio
Buon giorno Lista,
Ok, Ho tolto le cartelle di cui sopra.
Ed ho anche aggiunto la cartella /boot/grub/ con l'esclusione di
questo grub.cfg.
Ci sono altri files che contengono i dati del menu di grub per l'avvio iniziale ?
Il 18/04/2023 09:25, pinguino ha scritto:
Buon giorno Lista,
Ok, Ho tolto le cartelle di cui sopra.
Ed ho anche aggiunto la cartella /boot/grub/ con l'esclusione di
questo grub.cfg.
Ci sono altri files che contengono i dati del menu di grub per l'avvio
iniziale ?
grub.cfg tienitelo.... viene generato automaticamente dagli script di installazione, ma una copia non fa male ad averla.
Il 18/04/23 15:25, mauro morichi ha scritto:
Il 18/04/2023 09:25, pinguino ha scritto:
Buon giorno Lista,
Ok, Ho tolto le cartelle di cui sopra.
Ed ho anche aggiunto la cartella /boot/grub/ con l'esclusione di
questo grub.cfg.
Ci sono altri files che contengono i dati del menu di grub per
l'avvio iniziale ?
grub.cfg tienitelo.... viene generato automaticamente dagli script di
installazione, ma una copia non fa male ad averla.
Buon giorno Lista,
Si, ho fatto le copie di grub.cfg e fstab.
Ma nel mio caso ora anche quando faccio update-grub, poi il file di grub
lo devo modificare a mano, perché lui mi mette degli UUID diversi nei
posti sbagliati. Quindi i vari sistemi non partono, all'avvio.
Grazie
Saluti
Claudio
Ciao.
Just my 2c
Diego
Ciao.
simili, mentre col disaster recovery ripristini tutto il sistema ad uno
stato noto e funzionante.
Di certo la fortuna di non aver mai avuto rotture al disco col s.o. mi ha impigrito, ma è ora che mi svegli, no?
Buon giorno Lista,Utile, ma non indispensabile, se fai periodicamente immagini di disaster recovery.In pratica, col backup recuperi i file cancellati per errore o coseMi aggancio qui.
simili, mentre col disaster recovery ripristini tutto il sistema ad uno
stato noto e funzionante.
Finora io ho fatto solo copia in un disco esterno di /home e /root
Ok, ora aggiungo /etc
Per l'altro aspetto, per il "disaster recovery", quali consigli avete?Mi sono sempre trovato bene con CloneZilla. Ma se proprio sei alla canna
del gas puoi anche usare semplicemente dd e bzip2 (o pigz, se c'è nella live).
Sul sistema live (knoppix?), sul supporto da usare (DVD? disco USBSicuramente supporti separati. Poi devi valutare tu cosa usare. Se
esterno?), quali partizioni e poi supporti separati o no?
magari hai un vecchio NAS che normalmente tieni spento, puoi usare
quello. O un disco USB. O un DVD, se è sufficiente. O anche un tape.
Con che criteri decidere la frequenza dei backup?Alcune domande a cui devi rispondere:
- Quanto puoi permetterti di perdere senza dover poi sputare i peli?
- Quanto tempo sei disposto ad investire?
- Quanto spesso modifichi il sistema?
- Quanto tempo può rimanere spento il sistema sotto backup (poco significativo per un PC di casa, ma per un server è importante, tanto
che si usano altri sistemi)?
- Tieni un diario di root dove indichi tutte le modifiche che apporti al sistema?
Per un PC di casa potresti p.e. decidere di fare un'immagine al mese, un'immagine extra prima di un aggiornamento di sistema (e magari
un'altra dopo averlo testato), sincronizzazione giornaliera delle home
verso un NAS o un disco esterno, sincronizzazione settimanale delle home
su un disco esterno (diverso dal precedente, meglio se a rotazione tra
due).
Alla fine è "solo" questione di bilanciare costi (dischi esterni, tempo)
e rischi (perdere dati per guasto, ransomware, errore umano).
Il pc è recente e UEFI.Non significativo.
Di certo la fortuna di non aver mai avuto rotture al disco col s.o. miCertamente. Il giorno migliore per iniziare a fare backup era ieri. La seconda scelta è oggi. Domani è tardi.
ha impigrito, ma è ora che mi svegli, no?
E ricordati di fare prove di restore dei backup! Un backup non testato è
un backup non fatto!
[...]
Per un backup di sistema ("disaster recovery") allora conviene fare un'immagine del disco (o per lo meno delle partizioni di sistema,
escludendo /home che viene già backuppata separatamente). Questo però richiede un boot da una chiavetta con sistema live (in generale non
puoi fare immagini consistenti di filesystem montati).
veramente se i filesystem fossero su LVM non sarebbe necessario partireposso chiederti perchè? Uso LVM su alcune VM più per abitudine che altro,
da una live
On 4/19/23 14:46, Diego Zuccato wrote:
[...]
Per un backup di sistema ("disaster recovery") allora conviene fare un'immagine del disco (o per lo meno delle partizioni di sistema, escludendo /home che viene già backuppata separatamente). Questo però richiede un boot da una chiavetta con sistema live (in generale non
puoi fare immagini consistenti di filesystem montati).
veramente se i filesystem fossero su LVM non sarebbe necessario partire
da una live
Piviul
Infatti avevo scritto "in generale". E comunque è sempre problematico fare lo snapshot sincrono di più partizioni, magari su dischi diversi.
Proxmox risolve mettendo in suspend la VM mentre crea il punto di snapshot, poi la sblocca e tutte le scritture vanno in un log fino a che non viene cancellato lo snapshot (o sposta nel log i settori che vengono sovrascritti, non ricordo esattamente).
Ma è inapplicabile ad una macchina fisica.
E comunque anche con lo snapshot quando fai il restore è poco meno grave della situazione che ti ritroveresti dopo un reset brutale. Alcuni FS collaborano meglio di altri con LVM, ma nulla batte un umount pulito.
Infatti avevo scritto "in generale". E comunque è sempre problematico
fare lo snapshot sincrono di più partizioni, magari su dischi diversi. Proxmox risolve mettendo in suspend la VM mentre crea il punto di
snapshot, poi la sblocca e tutte le scritture vanno in un log fino a
che non viene cancellato lo snapshot (o sposta nel log i settori che
vengono sovrascritti, non ricordo esattamente). Ma è inapplicabile ad
una macchina fisica.
E comunque anche con lo snapshot quando fai il restore è poco meno
grave della situazione che ti ritroveresti dopo un reset brutale.
Alcuni FS collaborano meglio di altri con LVM, ma nulla batte un
umount pulito.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 09:47:28 |
| Calls: | 6,666 |
| Files: | 12,213 |
| Messages: | 5,336,330 |