Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.os.linux.sys > #44884 > unrolled thread

backup su disco usb

Back to article view | Back to it.comp.os.linux.sys

Contents

  backup su disco usb Enrico Maria Chellini <bitit@bitit.it> - 2023-03-29 15:45 +0200
    Re: backup su disco usb rootkit <rootkit@email.it> - 2023-03-29 15:28 +0000
      Re: backup su disco usb Enrico Maria Chellini <bitit@bitit.it> - 2023-03-29 17:45 +0200
        Re: backup su disco usb Giuseppe Della Bianca <giusdbgNO@gmailNO.comNO> - 2023-03-31 21:06 +0000
          Re: backup su disco usb Enrico Maria Chellini <bitit@bitit.it> - 2023-04-01 09:37 +0200
            Re: backup su disco usb rootkit <rootkit@email.it> - 2023-04-01 09:43 +0000
              Re: backup su disco usb Enrico Maria Chellini <bitit@bitit.it> - 2023-04-01 12:07 +0200
                Re: backup su disco usb rootkit <rootkit@email.it> - 2023-04-01 13:44 +0000
                  Re: backup su disco usb Enrico Maria Chellini <bitit@bitit.it> - 2023-04-01 16:08 +0200
                    Re: backup su disco usb rootkit <rootkit@email.it> - 2023-04-01 15:40 +0000
                      Re: backup su disco usb Piergiorgio Sartor <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> - 2023-04-01 18:29 +0200
                        Re: backup su disco usb rootkit <rootkit@email.it> - 2023-04-01 18:51 +0000
                          Re: backup su disco usb Piergiorgio Sartor <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> - 2023-04-02 17:16 +0200
                            Re: backup su disco usb rootkit <rootkit@email.it> - 2023-04-02 18:27 +0000
      Re: backup su disco usb "massi...@gmail.com" <massimo79m@gmail.com> - 2023-03-30 07:15 -0700
        Re: backup su disco usb "massi...@gmail.com" <massimo79m@gmail.com> - 2023-03-30 07:16 -0700
        Re: backup su disco usb Enrico Maria Chellini <bitit@bitit.it> - 2023-03-30 17:06 +0200
          Re: backup su disco usb "massi...@gmail.com" <massimo79m@gmail.com> - 2023-03-31 07:10 -0700

#44884 — backup su disco usb

allora vorrei fare il backup su un disco usb; la mia paura è che se
arrivano a criptare mi criptano anche quello. 

che faccio lo monto e lo smonto dopo il backup con un paio di script
attivati da cron? 

troppo paranoico?


Enrico 

[toc] | [next] | [standalone]

#44885

Il Wed, 29 Mar 2023 15:45:30 +0200, Enrico Maria Chellini ha scritto:

> allora vorrei fare il backup su un disco usb; la mia paura è che se
> arrivano a criptare mi criptano anche quello.
> 
> che faccio lo monto e lo smonto dopo il backup con un paio di script
> attivati da cron?
> 
> troppo paranoico?

direi affatto paranoico, è buona prassi non tenere online i backup.
potresti anche criptare l'unità con luks, primo perché sui dispositivi 
rimovibili è buona norma farlo, e secondo perché se ci fosse un tentativo 
di montarlo fallirebbe non conoscendo le credenziali.
poi è ovvio, un attacco aggressivo che scala i privilegi potrebbe anche 
asfaltare il device a blocchi senza montarlo, ma non andrei troppo oltre. 
la sicurezza più completa ce l'avresti staccando proprio il dispositivo.

[toc] | [prev] | [next] | [standalone]

#44886

Il giorno Wed, 29 Mar 2023 15:28:38 -0000 (UTC)
rootkit <rootkit@email.it> ha scritto:

> Il Wed, 29 Mar 2023 15:45:30 +0200, Enrico Maria Chellini ha scritto:
> 
> > allora vorrei fare il backup su un disco usb; la mia paura è che se
> > arrivano a criptare mi criptano anche quello.
> > 
> > che faccio lo monto e lo smonto dopo il backup con un paio di script
> > attivati da cron?
> > 
> > troppo paranoico?  
> 
> direi affatto paranoico, è buona prassi non tenere online i backup.
> potresti anche criptare l'unità con luks, primo perché sui
> dispositivi rimovibili è buona norma farlo, e secondo perché se ci
> fosse un tentativo di montarlo fallirebbe non conoscendo le
> credenziali. poi è ovvio, un attacco aggressivo che scala i privilegi
> potrebbe anche asfaltare il device a blocchi senza montarlo, ma non
> andrei troppo oltre. la sicurezza più completa ce l'avresti staccando
> proprio il dispositivo.

ok. grazie .

sarebbe in farm, quindi non posso staccarlo.

enrico 

[toc] | [prev] | [next] | [standalone]

#44891

Il Wed, 29 Mar 2023 17:45:28 +0200, Enrico Maria Chellini ha scritto:

]zac[
> sarebbe in farm, quindi non posso staccarlo.
]zac[

Disco collegato ad un sistema non direttamente raggiungibile, nessun 
mount, nessun login, solo una chiave ssh per copiare i backup in aggiunta 
(e non in sostituzione).

ssh può essere impostato per consentire solo il lancio di un comando 
preciso.

Se c'è abbastanza spazio per una serie di backup, prima che la rotazione 
dei backup possa far diventare tutti i backup criptati, possono passare 
mesi o anni, i sistemi in uso manifesteranno l'attacco subito molto prima.

[toc] | [prev] | [next] | [standalone]

#44894

Il giorno Fri, 31 Mar 2023 21:06:50 -0000 (UTC)
Giuseppe Della Bianca <giusdbgNO@gmailNO.comNO> ha scritto:

> Il Wed, 29 Mar 2023 17:45:28 +0200, Enrico Maria Chellini ha scritto:
> 
> ]zac[
> > sarebbe in farm, quindi non posso staccarlo.  
> ]zac[
> 
> Disco collegato ad un sistema non direttamente raggiungibile, nessun 
> mount, nessun login, solo una chiave ssh per copiare i backup in
> aggiunta (e non in sostituzione).
> 
> ssh può essere impostato per consentire solo il lancio di un comando 
> preciso.
> 
> Se c'è abbastanza spazio per una serie di backup, prima che la
> rotazione dei backup possa far diventare tutti i backup criptati,
> possono passare mesi o anni, i sistemi in uso manifesteranno
> l'attacco subito molto prima.

 e quindi come faresti per non consumare banda, virtualizzi il sistema
 on line e  fai il backup nel sistema locale accedibile solo da ssh o
 viceversa?

Enrico 

[toc] | [prev] | [next] | [standalone]

#44895

Il Sat, 1 Apr 2023 09:37:04 +0200, Enrico Maria Chellini ha scritto:


>  e quindi come faresti per non consumare banda, virtualizzi il sistema
>  on line e  fai il backup nel sistema locale accedibile solo da ssh o
>  viceversa?

un altro sistema nella stessa rete interna, fisico o virtuale dipende da 
quello che offre il provider.
detto questo, in generale va bene non sprecare soldi, ma neanche fare le 
nozze coi fichi secchi. francamente usare un disco usb su un sistema in 
housing per fare i backup senza consumare banda lo trovo un accrocchio 
inaffidabile fonte solo di problemi. 

[toc] | [prev] | [next] | [standalone]

#44896

> un altro sistema nella stessa rete interna, fisico o virtuale dipende
> da quello che offre il provider.
dunque l'ultima conversazione che ho avuto con l'assistenza di una
farm, mi hanno detto che pago anche la banda per il back up, in ogni
caso la cosa è sempre fumosa.

diciamo che non la pago,  in ogni caso impiego risorse della macchina
per trasmettere dei dati, quando si arriva ad archivi importanti, non
so nel complesso quanto influisca, ma qualcosa influisce senz'altro

> detto questo, in generale va bene non sprecare soldi, ma neanche fare
> le nozze coi fichi secchi. 

purtroppo non tutti hanno a disposizione budget sufficiente per
infrastrutture importanti, ed in ogni caso cercare  soluzioni per
ottimizzare il tutto, non mi sembra sbagliato.

>francamente usare un disco usb su un
> sistema in housing per fare i backup senza consumare banda lo trovo
> un accrocchio inaffidabile fonte solo di problemi. 
 
sicuramente meno affidabile di uno storage in cloud, anche se la
sicurezza al 100% non ce l'ha nessuno;  a parte i costi ci sono varie
cause con aziende che offrono clouds e che hanno perso i dati .

l'idea comunque è due dischi in raid, se ne rompe uno, hai un allert e
lo sostituisci, che se ne rompa due insieme è possibile, ma remoto.

il server viene impostato in rootkit, quindi se  bucano l'accesso
tramite  utente, criptano l'home/utente non tutto il sistema.

ma anche se hai rotto tutti e due i dischi o ti hanno criptato
l'intero server, hai un back up incrementale su un disco usb, con
partizione criptata, che moti con uno script bash attivato da cron alle
1 di notte e lo smonti a backup finito. 

dove li vedi i problemi?

Enrico 

[toc] | [prev] | [next] | [standalone]

#44897

Il Sat, 1 Apr 2023 12:07:50 +0200, Enrico Maria Chellini ha scritto:


>>francamente usare un disco usb su un
>> sistema in housing per fare i backup senza consumare banda lo trovo un
>> accrocchio inaffidabile fonte solo di problemi.
>  
> sicuramente meno affidabile di uno storage in cloud, anche se la
> sicurezza al 100% non ce l'ha nessuno;  a parte i costi ci sono varie
> cause con aziende che offrono clouds e che hanno perso i dati .

non credo che il rischio di perdere i dati su un qualsiasi disco usb e 
quello di perdere i dati su (esempio) un bucket di aws siano anche 
lontanamente paragonabili. 
quanto ai costi con s3 glacier si parla di millesimi di euro al gb/mese, 
cioè con quello che spendi per un disco da 1tb ci tieni gli stessi dati 
per 5 anni buoni. e io sinceramente 5 anni un disco esterno non mi fiderei 
a tenerlo.

> ma anche se hai rotto tutti e due i dischi o ti hanno criptato l'intero
> server, hai un back up incrementale su un disco usb, con partizione
> criptata, che moti con uno script bash attivato da cron alle 1 di notte
> e lo smonti a backup finito.
> 
> dove li vedi i problemi?

ne vedo diversi. del rischio perdita dati ne abbiamo già parlato, aggiungo 
che a mio avviso non è affidabile usare un dispositivo rimovibile per i 
backup su un server dove hai solo accesso remoto. 

[toc] | [prev] | [next] | [standalone]

#44898

> non credo che il rischio di perdere i dati su un qualsiasi disco usb
> e quello di perdere i dati su (esempio) un bucket di aws siano anche 
> lontanamente paragonabili. 
> quanto ai costi con s3 glacier si parla di millesimi di euro al
> gb/mese, cioè con quello che spendi per un disco da 1tb ci tieni gli
> stessi dati per 5 anni buoni. e io sinceramente 5 anni un disco
> esterno non mi fiderei a tenerlo.


 3tb €.7/mese

ma non sono i costi di storage, sono le risorse che consumi meno,
a partire dal traffico contabilizzato, 

[toc] | [prev] | [next] | [standalone]

#44899

Il Sat, 1 Apr 2023 16:08:23 +0200, Enrico Maria Chellini ha scritto:

>> non credo che il rischio di perdere i dati su un qualsiasi disco usb e
>> quello di perdere i dati su (esempio) un bucket di aws siano anche
>> lontanamente paragonabili.
>> quanto ai costi con s3 glacier si parla di millesimi di euro al
>> gb/mese, cioè con quello che spendi per un disco da 1tb ci tieni gli
>> stessi dati per 5 anni buoni. e io sinceramente 5 anni un disco esterno
>> non mi fiderei a tenerlo.
> 
> 
>  3tb €.7/mese
> 
> ma non sono i costi di storage, sono le risorse che consumi meno,
> a partire dal traffico contabilizzato,

il traffico lo paghi solo sul recupero, che per un backup si suppone non 
sia così frequente. in upload non paghi il traffico, paghi solo le request 
tipo qualche cent per mille request, roba trascurabile. 

poi per carità, non voglio mica insistere ognuno giustamente valuta il 
proprio. 
 

[toc] | [prev] | [next] | [standalone]

#44900

On 01/04/2023 17.40, rootkit wrote:
[...]
> il traffico lo paghi solo sul recupero, che per un backup si suppone non

Stai in pratica scrivendo che tengono
in ostaggio i tuoi dati.

"Se vuoi rivedere i documenti, metti
le banconote, piccolo taglio, in una
valigetta anonima e depositala, poco
prima di mezzanotte, al cimitero,
sulla tomba senza nome vicina a quella
di Arch Stanton"

> sia così frequente. in upload non paghi il traffico, paghi solo le request
> tipo qualche cent per mille request, roba trascurabile.

Si, ma questo prezzo e` fisso, oppure
te lo possono cambiare quando e come
vogliono (cosa c'e` nel contratto)?

Perche`, a mio avviso, c'e` un problema
in una situazione del genere.

bye,

-- 

piergiorgio

[toc] | [prev] | [next] | [standalone]

#44901

Il Sat, 1 Apr 2023 18:29:30 +0200, Piergiorgio Sartor ha scritto:

> On 01/04/2023 17.40, rootkit wrote: [...]
>> il traffico lo paghi solo sul recupero, che per un backup si suppone
>> non
> 
> Stai in pratica scrivendo che tengono in ostaggio i tuoi dati.

è un punto di vista. 

> Si, ma questo prezzo e` fisso, oppure te lo possono cambiare quando e
> come vogliono (cosa c'e` nel contratto)?

possono cambiarlo, così come il suo provider può cambiare quando e come 
vuole il canone per il server dedicato. 

[toc] | [prev] | [next] | [standalone]

#44902

On 01/04/2023 20.51, rootkit wrote:
[...]
>>> il traffico lo paghi solo sul recupero, che per un backup si suppone
>>> non
>>
>> Stai in pratica scrivendo che tengono in ostaggio i tuoi dati.
> 
> è un punto di vista.

Interpretavo solo la descrizione.

>> Si, ma questo prezzo e` fisso, oppure te lo possono cambiare quando e
>> come vogliono (cosa c'e` nel contratto)?
> 
> possono cambiarlo, così come il suo provider può cambiare quando e come
> vuole il canone per il server dedicato.

Si, ma c'e` una grande differenza.

Se il provider cambia il canone, si
puo` cambiare provider e fine.

Se il backup cambia prezzo per il
recupero, per cambiare, si deve
comunque fare il recupero dei dati.
Oppure cambiare e sperare che non
succeda niente per un certo tempo.

E` un rischio, tanto quanto il
rischio che si rompa un HDD.

E siccome se si devono recuperare i
dati vuol dire che e` *necessario*,
cioe` si deve fare, costi quel che
costi, allora praticamente ci si
trova con le brache calate...

bye,

-- 

piergiorgio

[toc] | [prev] | [next] | [standalone]

#44903

Il Sun, 2 Apr 2023 17:16:36 +0200, Piergiorgio Sartor ha scritto:


>>> Si, ma questo prezzo e` fisso, oppure te lo possono cambiare quando e
>>> come vogliono (cosa c'e` nel contratto)?
>> 
>> possono cambiarlo, così come il suo provider può cambiare quando e come
>> vuole il canone per il server dedicato.
> 
> Si, ma c'e` una grande differenza.
> 
> Se il provider cambia il canone, si puo` cambiare provider e fine.

eh già, migrare dei server dedicati da un provider all'altro, che vuoi che 
costi? :-)
 
> Se il backup cambia prezzo per il recupero, per cambiare, si deve
> comunque fare il recupero dei dati.
> Oppure cambiare e sperare che non succeda niente per un certo tempo.
> 
> E` un rischio, tanto quanto il rischio che si rompa un HDD.
> 
> E siccome se si devono recuperare i dati vuol dire che e` *necessario*,
> cioe` si deve fare, costi quel che costi, allora praticamente ci si
> trova con le brache calate...

ok, ma ora però torniamo seri: recuperare un tera di dati da glacier costa 
12$, queste sono le cifre di cui si sta parlando, *dodici* dollari a 
terabyte.

certo, fossero dati con frequenti letture e scritture la questione costi 
sarebbe tutt'altro che trascurabile. ma stiamo parlando dei backup: i 
backup li tiri giù alla bisogna, quella volta che ti serve o al massimo 
ogni tot mesi quando fai i test di restore. per il resto è tutto traffico 
in upload (senza costi).

realmente è il caso di fare tutta questa melina, sentirsi con "le braghe 
calate" per una questione di qualche decina di dollari? se è così alzo le 
mani, vuol dire che ho frainteso clamorosamente il target di utenza.

[toc] | [prev] | [next] | [standalone]

#44887

Il giorno mercoledì 29 marzo 2023 alle 17:28:40 UTC+2 rootkit ha scritto:

> la sicurezza più completa ce l'avresti staccando proprio il dispositivo.

cosa ne diresti del compilare il kernel senza supporto a device dischi usb e caricare il modulo (tenuto in una dir fuori dal gruppo di dir in cui modprobe cerca i moduli) giusto per lo scarico e poi scaricare il modulo?
e' un po' macchinoso, ma non penso i malware siano cosi' "intelligenti" da farlo.

[toc] | [prev] | [next] | [standalone]

#44888

Il giorno giovedì 30 marzo 2023 alle 16:15:24 UTC+2 massi...@gmail.com ha scritto:
> giusto per lo scarico 

intendevo "giusto per il backup"

[toc] | [prev] | [next] | [standalone]

#44889

Il giorno Thu, 30 Mar 2023 07:15:22 -0700 (PDT)
"massi...@gmail.com" <massimo79m@gmail.com> ha scritto:

> Il giorno mercoledì 29 marzo 2023 alle 17:28:40 UTC+2 rootkit ha
> scritto:
> 
> > la sicurezza più completa ce l'avresti staccando proprio il
> > dispositivo.  
> 
> cosa ne diresti del compilare il kernel senza supporto a device
> dischi usb e caricare il modulo (tenuto in una dir fuori dal gruppo
> di dir in cui modprobe cerca i moduli) giusto per lo scarico e poi
> scaricare il modulo? e' un po' macchinoso, ma non penso i malware
> siano cosi' "intelligenti" da farlo.

mi pare un po' troppo, anche perchè  uscendo da configurazioni
standard, non vorrei ci fossero problemi con l'upgrade, per un server
in produzione richiederebbe un costo di manutenzione troppo elevato.

magari mi sbaglio.

Enrico 

[toc] | [prev] | [next] | [standalone]

#44890

Il giorno giovedì 30 marzo 2023 alle 17:06:48 UTC+2 Enrico Maria Chellini ha scritto:

> mi pare un po' troppo, anche perchè uscendo da configurazioni 
> standard, non vorrei ci fossero problemi con l'upgrade, per un server 
> in produzione richiederebbe un costo di manutenzione troppo elevato. 

Piu' che giusto

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.os.linux.sys

csiph-web