Avviare un task snapshot da remoto

proto

Patron
Joined
Sep 28, 2015
Messages
269
Ho allegato lo schema spero si capisca meglio

allora, non avevo dubbi che fosse così : P
ma è più chiaro!

In soldoni devi trovare il modo di agganciare il tuo TASK FTP al TASK SNAPSHOT nei giorni di turno festivi.

Nel commento del tuo schema chiedi "se fosse possibile, attraverso una pagina web, avviare il processo di snapshot":
quindi, ripeto, dal momento che FreeNAS espone le API per gli snapshot perché non usi quelle?
Tanto mettere un tuo script (php?) sul web server di freenas non puoi e chiaramente se non puoi schedulare la cosa per via dei turni dovrai lanciare per forza il comando "manualmente" o attraverso un'automazione.

In sostanza, io farei in questo modo:

Screenshot 2019-07-27 09.17.44.png

1) Automatizzato
il SERVER ha due task collegati per i turni festivi.

PRO: facile da gestire, unico punto di accesso.
CONTRO: insicuro perché devi utilizzare l'autenticazione tramite root/password in uno script che funge da client REST per il server NAS

2) Semi-automatizzato
a) un CLIENT esterno si collega al SERVER e lancia TASK FTP
b) attende OK/KO e se OK:
c) si collega al NAS ed esegue TASK SNAPSHOT
d) CLIENT riceve OK/KO dello SNAPSHOT

PRO: più sicuro. Le utenze non sono su SERVER.
CONTRO: implementazione un po' più complessa, necessita di automation engine tipo ansible

Tuto questo per dirti che: non puoi evitare di utilizzare una forma di autenticazione per fare ciò che desideri sul NAS, vuoi via WEB vuoi via SSH, a meno che tu non voglia smanettare più o meno pesantemente sul motore python di FreeNAS e con risultati incerti... oppure se possibile, creare un demone con un microframework tipo flask o bottle, che esponga tramite modulo subprocess una paginetta web su porta XXXX e che lanci, come per exec() di php un popen() di zfs snapshot... mah, sarebbe una porcheria.
 

glauco

Guru
Joined
Jan 30, 2017
Messages
526
Soluzione semplice semplice: su Freenas metti uno shell script in crontab che ogni 5 minuti fa md5 della cartella con i dati sincronizzati dal server. Se sono cambiati rispetto all'ultima volta, zfs snapshot.
 

squalo

Dabbler
Joined
Jul 24, 2019
Messages
22
Soluzione semplice semplice: su Freenas metti uno shell script in crontab che ogni 5 minuti fa md5 della cartella con i dati sincronizzati dal server. Se sono cambiati rispetto all'ultima volta, zfs snapshot.
Ottima idea! Appena posso provo!! Mi sapresti anche indicare se esiste già uno script del genere ( peró fare md5 di 1 milione e mezzo di file credo che ci voglia molto tempo oltre al fatto che mette il nas e l hd della sincronizzazione sotto sforzo). Peró l idea non é male! Potrei creare un file apposito che cambi alla fine della sync e quindi fare il controllo solo di quel file!
 

glauco

Guru
Joined
Jan 30, 2017
Messages
526
Ci mette una frazione di secondo, prova!
 

glauco

Guru
Joined
Jan 30, 2017
Messages
526
Ho fatto lo script, vedi se ti funziona: https://pastebin.com/pgKpcpg9
Md5 sulla cartella non funziona se a cambiare sono file nelle sottocartelle, quindi l'ho fatto su un file il cui contenuto devi fare in modo che cambi ad ogni sincronizzazione.
 
Last edited:

squalo

Dabbler
Joined
Jul 24, 2019
Messages
22
Ho fatto lo script, vedi se ti funziona: https://pastebin.com/x8LK07wf
Md5 sulla cartella non funziona se a cambiare sono file nelle sottocartelle, quindi l'ho fatto su un file il cui contenuto devi fare in modo che cambi ad ogni sincronizzazione.
Wow grazie mille, non posso provare nulla per adesso, forse domani posso! Ti faccio sapere.
Grazie ancora
 

glauco

Guru
Joined
Jan 30, 2017
Messages
526
Ieri avevo caricato il codice dello script su Pastebin da semplice ospite, ma oggi mi sono accorto che c'era un errore, quindi ho creato un account e l'ho ricaricato, così posso anche modificarlo, se trovo altri errori.
Mi è venuto in mente che forse conviene fare due sincronizzazioni, prima con i file che hai sempre sincronizzato, e poi con questo file "di controllo", che nello script ho chiamato "dummy", per escludere che lo snapshot sia avviato prima che i file importanti abbiano terminato la sincronizzazione.
 

squalo

Dabbler
Joined
Jul 24, 2019
Messages
22
Ieri avevo caricato il codice dello script su Pastebin da semplice ospite, ma oggi mi sono accorto che c'era un errore, quindi ho creato un account e l'ho ricaricato, così posso anche modificarlo, se trovo altri errori.
Mi è venuto in mente che forse conviene fare due sincronizzazioni, prima con i file che hai sempre sincronizzato, e poi con questo file "di controllo", che nello script ho chiamato "dummy", per escludere che lo snapshot sia avviato prima che i file importanti abbiano terminato la sincronizzazione.
Sarà mia premura generare il dummy dopo aver finito la sync! Grazie ancora

Adesso solo una cosa non ho capito, se configuro uno snapshot, non dovrei impostare una sorgente ed una destinazione?
Ad esempio

zfs list
Code:
NAME     USED  AVAIL  REFER  MOUNTPOINT
Backup  2.23M   449G    88K  /mnt/Backup
Sync    46.3G   178G  46.3G  /mnt/Sync


zpool list
Code:
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
Backup   464G  2.36M   464G        -         -     0%     0%  1.00x  ONLINE  -
Sync     232G  46.3G   186G        -         -     3%    19%  1.00x  ONLINE  -


Backup è il nome del Pool e del dataset in cui dovrò salvare gli snapshot
Sync è il nome del Pool e del dataset che contiene i file

Se do il comando:
zfs snapshot Backup/Sync@NomeDelloSnapshotConData

Ma ovviamente così non può funzionare (la sintassi è sicuramente errata) ma non capisco come fare.

Se invece faccio
zfs snapshot Sync@prova

Mi aggiunge lo snapshot ma resta a 0byte e non riesco a capire in qualunque caso la destinazione

EDIT
Ho appena scoperto che alla fine lo snapshot mi serve a poco (MEA CULPA).
Ma è mai possibile che un sistema del genere non preveda la creazione di semplici backup?
è Impensabile una cosa del genere
 

glauco

Guru
Joined
Jan 30, 2017
Messages
526
Gli snapshot fanno perfettamente al caso tuo, é solo che non hai capito bene come funzionano. Studiateli bene. Man zfs.
 

squalo

Dabbler
Joined
Jul 24, 2019
Messages
22
Gli snapshot fanno perfettamente al caso tuo, é solo che non hai capito bene come funzionano. Studiateli bene. Man zfs.
Ma io lo sto studiando :eek: ma ci sono alcune cose che non ho capito!
Ho capito che lo snapshot copia sullo stesso hd il file system (quindi se l'hd si rompe si perdono gli snapshot)
Quindi ho capito che dovrei clonare gli snapshot in altri zpool. Ma quello che veramente mi rende scettico è la dimensione degli snapshot che si sono creati, pochi kb... come è possibile? Non dovrebbe raddoppiarsi la quantità di spazio utilizzata nell'hd della sincronizzazione?

Grazie
 

proto

Patron
Joined
Sep 28, 2015
Messages
269
Ma è mai possibile che un sistema del genere non preveda la creazione di semplici backup?
è Impensabile una cosa del genere

Un NAS non è un sistema di backup e zfs non sostituisce i sistemi di backup classici, è un fs avanzato: "tutto" qui.
Se vuoi un sistema di backup classico esistono jail che fanno da server di backup. Bacula ad esempio.

In ogni caso a me sembra un sistema fragile (tra l'altro non conosciamo nemmeno le spec hardware del tuo NAS): un singolo disco + un raid mirror (Sync / Backup). Cosa succede se il disco di Sync si rompe? Considerando che devi fare back di dati importanti e forse "delicati" farei attenzione a questo aspetto.

Insomma è da rivedere un po' il tutto e chiaramente studiare, implementare, testare... etc.

Comunque credo converrebbe fare zfs send | zfs receive tra i due pool o rsync. Ma verifica per sicurezza.
In questo caso potresti avere singoli snapshots su SYNC, backup completi su BACKUP ed in sostanza avresti i "differenziali" sul primo e il full sul secondo.


#######

Ho fatto lo script
Va benissimo. Io metterei una funzione di logging, ma userei sh per crontab, es:

Code:
#!/bin/sh
# variabili
LOG='logger -p local7.notice -t snapshot_job'  # logga in messages

snap () {
echo "### BEGIN SNAPSHOT JOB @ `date +\%Y.\%m.\%d_\%H.\%M`###"
# Script:
# il tuo script
echo "### END SNAPSHOT JOB @ `date +\%Y.\%m.\%d_\%H.\%M`###"
} # aggiungi ^^^ prima della chiusura della funzione

snap | $LOG



Diciamo che la funzione ha senso se lo fai girare con cadenze > di 5 minuti altrimenti diventa un log noiosissimo.
Volendo si potrebbe inserire anche un alert via mail/messages (tipo slack) acchiappandolo dalla conf di freenas.

PS: se sono ~10 runs all'anno converrebbe usare at invece di crontab; i turni della farmacia saranno ben dichiarati tempo prima spero, almeno dalle mie parti è così.
 

squalo

Dabbler
Joined
Jul 24, 2019
Messages
22
Un NAS non è un sistema di backup e zfs non sostituisce i sistemi di backup classici, è un fs avanzato: "tutto" qui.
Se vuoi un sistema di backup classico esistono jail che fanno da server di backup. Bacula ad esempio.
Bacula l'ho provato una volta e non mi è piaciuto più di tanto!

In ogni caso a me sembra un sistema fragile (tra l'altro non conosciamo nemmeno le spec hardware del tuo NAS): un singolo disco + un raid mirror (Sync / Backup). Cosa succede se il disco di Sync si rompe? Considerando che devi fare back di dati importanti e forse "delicati" farei attenzione a questo aspetto.

Per quanto riguarda l'hardware, è ininfluente: sto facendo delle prove se il risultato dovesse essere soddisfacente allora lo potenzierei in base all'assorbimento delle risorse. Se dovesse rompersi sync, semplicemente lo sostituirei! Pensare che si rompi il raid SSD presente nel server + l'hd di Sync + il raid dei 2 hd per backup è abbastanza impensabile! (Questo lo faccio principalmente per la questione ransomware)

Insomma è da rivedere un po' il tutto e chiaramente studiare, implementare, testare... etc.

Comunque credo converrebbe fare zfs send | zfs receive tra i due pool o rsync. Ma verifica per sicurezza.
In questo caso potresti avere singoli snapshots su SYNC, backup completi su BACKUP ed in sostanza avresti i "differenziali" sul primo e il full sul secondo.


#######


Va benissimo. Io metterei una funzione di logging, ma userei sh per crontab, es:

Code:
#!/bin/sh
# variabili
LOG='logger -p local7.notice -t snapshot_job'  # logga in messages

snap () {
echo "### BEGIN SNAPSHOT JOB @ `date +\%Y.\%m.\%d_\%H.\%M`###"
# Script:
# il tuo script
echo "### END SNAPSHOT JOB @ `date +\%Y.\%m.\%d_\%H.\%M`###"
} # aggiungi ^^^ prima della chiusura della funzione

snap | $LOG



Diciamo che la funzione ha senso se lo fai girare con cadenze > di 5 minuti altrimenti diventa un log noiosissimo.
Volendo si potrebbe inserire anche un alert via mail/messages (tipo slack) acchiappandolo dalla conf di freenas.

PS: se sono ~10 runs all'anno converrebbe usare at invece di crontab; i turni della farmacia saranno ben dichiarati tempo prima spero, almeno dalle mie parti è così.
Grazie per la funzione log, al massimo, per ovviare al problema delle innumerevoli scritture nel file log, basta che il log, con il relativo script, venga eseguito solo se il file dummy ha cambiato il suo md5!

10 runs? Io ne devo fare 2 al giorno! Per i turni si, sono dichiarati ad inizio anno, ma è impensabile dover riconfigurare il nas ogni anno quando ho già pronto un sistema che crea il calendario dei turni con i rispettivi orari di chiusura ed apertura della farmacia, pianifica tutti power on/power off dei dispositivi, tutte le operazioni di backup ecc.. Inoltre i turni estivi vengono decisi in breve tempo qualche giorno prima dell'inizio di giugno. Con tutto il sistema che ho fatto mi basta cambiare l'ordine e gli eventuali orari e automaticamente, senza pensieri, è tutto già pronto per funzionare alla perfezione
 
Last edited:

proto

Patron
Joined
Sep 28, 2015
Messages
269
10 runs? Io ne devo fare 2 al giorno!

10 o NN x2 runs all'anno per i soli TURNI, intendo. I backup feriali li lasci a crontab o come preferisci. Per questo meditavo su at.
 

squalo

Dabbler
Joined
Jul 24, 2019
Messages
22
10 o NN x2 runs all'anno per i soli TURNI, intendo. I backup feriali li lasci a crontab o come preferisci. Per questo meditavo su at.
I turni sono circa 35/40 giorni all anno, inoltre penso che tu possa convenire con me che diverrebbe tutto molto più inultilmente macchinoso! Dover creare metodi differenti per i giorni normali, i turni, i festivi... è assurdo, avendo inoltre la possibilità di avviare un unico task quando serve
 
Last edited:

proto

Patron
Joined
Sep 28, 2015
Messages
269
I turni sono circa tra i 35/40 giorni all anno inoltre penso che tu possa convenire con me che diverrebbe tutto molto più inultilmente macchinoso! Dover creare metodi differenti per i giorni normali, i turni, i festivi... è assurdo potendo avviare precisamente un unico task quando serve

e' molto scomodo, sicuro!

Comunque: mi chiarisci solo una cosa? Come sono messi fisicamente i server? Sono su stessa rete o sono geograficamente separati? Il gestionale è Windows o Linux? Questo non l'ho proprio capito o me lo sono perso.
 

squalo

Dabbler
Joined
Jul 24, 2019
Messages
22
e' molto scomodo, sicuro!

Comunque: mi chiarisci solo una cosa? Come sono messi fisicamente i server? Sono su stessa rete o sono geograficamente separati? Il gestionale è Windows o Linux? Questo non l'ho proprio capito o me lo sono perso.
Il server è uno solo, il gestionale è su windows server 2016.
Il nas é ubicato in un altro piano, ma stessa rete.
 

proto

Patron
Joined
Sep 28, 2015
Messages
269
Il server è uno solo, il gestionale è su windows server 2016.
Il nas é ubicato in un altro piano, ma stessa rete.

OK.
Vado un po' OT: non saresti più sicuro separando la rete server da quella client?
Meno superficie di attacco per ransom&Co.
 

squalo

Dabbler
Joined
Jul 24, 2019
Messages
22
OK.
Vado un po' OT: non saresti più sicuro separando la rete server da quella client?
Meno superficie di attacco per ransom&Co.
Accetto volentieri consigli! Quale sarebbe secondo te la strategia migliore?
Grazie
 

proto

Patron
Joined
Sep 28, 2015
Messages
269
Le opzioni potrebbero essere:
1) lasci così com'è la rete, ma configuri il firewall di Windows e le policy di accesso applicazione. In sostanza: blocchi il traffico in entrata/uscita dal server salvo per determinati servizi e app (updates, rdp, gestionale...). In sostanza: no internet.
2) vlans e firewall per separare la rete server da quella client. Sul firewall permetti/blocchi accesso a rete e risorse.
3) fw trasparente... ma siamo oltre.
Tutta questa roba però è OT qua quindi ti conviene fare riferimento a qualche forum di networking/firewalling/windows...

Tornando in topic: quale sia la tua preferenza per gestire i backup, assicurati di utilizzare un client FTP affidabile che permetta il resume delle trasmissioni. Su windows non so nulla però!
 

squalo

Dabbler
Joined
Jul 24, 2019
Messages
22
1) Internet è fondamentale in una farmacia!
2) Tanto il gestionale è fatto male, richiede la condivisione di tutto l'hd del server (per funzionare con acuthin) ma comunque i terminali lavorano tutti in rdp
3) A che pro? Non posso limitare la navigazione
 
Top