Nata per offrire alle aziende soluzioni end-to-end di software e marketing digitale, Partnerfy è il partner tecnologico affidabile di agenzie e brand.
Che ne dice di programmare il futuro con noi?
«Il backup c'è?» — la risposta deve essere sì, ma non basta. La vera domanda è: «Riusciamo davvero a ripristinare, in quanto tempo e con quanta perdita di dati?». Backup cifrati ogni ora, tre copie su due supporti di cui una off-site, storage WORM immutabile, esercitazioni di ripristino reali ogni tre mesi e obiettivi RPO/RTO espliciti — ecco l'unica cosa che conta nel giorno peggiore.
Un ripristino non testato non è un backup — è una speranza. Noi non vendiamo speranza: consegniamo tempi di recupero misurabili e report di ripristino comprovati.
Quando il sistema primario si ferma, il secondario subentra automaticamente — verificato con esercitazioni reali.
Prima dura verità: la stragrande maggioranza dei backup non viene mai testata. Il cron gira ogni notte, il log dice «OK», la dashboard di monitoraggio è verde — ma quando prova davvero a ripristinare quel backup, i file sono corrotti, la chiave di decifratura non si trova o la versione dello schema è incompatibile. Finché non è stato ripristinato, un backup non è un backup: è solo una speranza. Con ogni cliente rendiamo obbligatoria un'esercitazione di ripristino completo almeno ogni tre mesi e documentiamo il risultato.
Secondo problema: gran parte di ciò che viene chiamato «backup» è in realtà uno snapshot che risiede sullo stesso server di produzione. Una copia che condivide lo stesso disco, che può essere scritta dallo stesso account e che brucerebbe nello stesso incendio non è un backup: è un secondo nome per gli stessi dati. In caso di guasto hardware, attacco ransomware o tabella cancellata per errore, quel «backup» sparisce insieme ai dati di produzione. Un vero backup deve risiedere su un sistema separato, con un'identità separata e, idealmente, in un'area geografica separata.
Terzo problema: nessuna copia off-site. Un backup che risiede in un solo data center o in una sola regione cloud diventa irraggiungibile se quella regione va fuori servizio, viene colpita da una calamità naturale o se l'account viene sospeso. AWS può fermare un'intera regione, Microsoft può bloccare un account nel giro di poche ore, l'incendio di un data center può durare ore — in questi scenari una copia off-site è l'unica cosa che separa la continuità operativa dalla bancarotta. Il numero «1» della regola 3-2-1 non è negoziabile.
Quarto problema: backup non cifrati. Un file di backup è una copia completa del suo database di produzione — ogni record dei clienti, ogni traccia di carta di credito, ogni hash delle password e ogni comunicazione interna stanno dentro un unico tar.gz. Se quel file viene rubato, una violazione resta una violazione: GDPR e KVKK (legge turca n. 6698 sulla protezione dei dati personali) non fanno sconti solo perché si trattava di un backup. Tutti i backup devono essere cifrati sia at-rest (AES-256) sia in-transit (TLS 1.3), con le chiavi custodite in un KMS separato dal sistema di backup — altrimenti il backup è una superficie di attacco, non una difesa.
Quinto problema: nessuna immutabilità. Il ransomware moderno non si limita a cifrare i dati di produzione — l'attaccante entra prima nel sistema di backup, cancella o invalida i backup degli ultimi tre mesi e solo dopo cifra la produzione. Se gli account di backup condividono la stessa directory, la stessa VPN e lo stesso SSO della produzione, il ransomware li troverà. La soluzione: storage WORM (write-once-read-many), S3 Object Lock, un Veeam Hardened Repository, una copia offline air-gapped — in breve, un livello in cui la cancellazione è matematicamente impossibile anche con credenziali amministrative.
Una timeline di ripristino, una simulazione di bonifica dal ransomware e un pannello di confronto RPO/RTO — rendono misurabili in anticipo le decisioni da prendere dopo un disastro.
Snapshot orari + backup completi giornalieri + consolidamento settimanale + archivio mensile. Punto di ripristino selezionabile al secondo.
Dati cifrati → ripristino da backup immutabile → dati puliti contrassegnati da una spunta verde.
Veda a colpo d'occhio la differenza tra «nessun backup» e la nostra architettura.
Un'ora di dati persi significa centinaia di ordini, migliaia di movimenti di magazzino e riconciliazioni dei pagamenti saltate.
Per recuperare i dati di un singolo tenant, ripristinare l'intera tabella non è un'opzione.
Le cartelle cliniche vanno conservate per anni in modo verificabile; ogni perdita è una violazione di KVKK/HIPAA.
I dati richiesti da BDDK, SPK e MASAK (autorità finanziarie turche) vanno conservati per anni senza essere cancellati né modificati.
Se perde file di design, progetti video e repository di codice, dovrà chiamare i clienti uno a uno.
Petabyte di girato grezzo e materiale storico irriproducibile: serve un'architettura dedicata.
Se si perde la configurazione di un solo controller, la linea di produzione resta ferma per ore.
Diplomi, certificati degli esami e presenze devono restare continui, duraturi e verificabili.
Dalla progettazione della strategia al runbook, dieci livelli in un unico pacchetto — nessuno saltato, nessuno gonfiato.
Analisi di impatto sul business, inventario degli asset, matrice RPO/RTO e obiettivi contrattuali.
Appliance di backup fisica o virtuale in sede per ripristini più rapidi.
Replica asincrona o sincrona verso un altro data center o una regione cloud.
Backup a costi ottimizzati con policy di ciclo di vita su S3, Blob e GCS.
S3 Object Lock, Wasabi Compliance, Veeam Hardened — il livello che non si può cancellare.
PostgreSQL WAL, MySQL binlog, MongoDB oplog, transaction log MSSQL.
VSS, fsfreeze e hook pre/post per immagini disco coerenti durante la scrittura.
Ripristini periodici in sandbox + verifica dell'integrità + report.
Piano scritto passo per passo: chi fa cosa, chi approva, chi registra.
Attivazione → isolamento → analisi forense → ripristino → immagine pulita verificata con analisi forense.
Si definiscono la criticità di ogni sistema, la perdita di dati accettabile e i tempi di ripristino; si esegue l'analisi di impatto sul business.
Tre copie, due supporti, un livello off-site; immutabilità, cifratura e modello di accesso vengono documentati.
Appliance on-site, account cloud, isolamento di rete, monitoraggio e alerting vengono attivati.
Ciclo orario / giornaliero / settimanale / mensile; AES-256 at-rest, TLS in-transit, chiavi separate in KMS.
Ripristini con scenari reali; RPO/RTO misurati a confronto con gli obiettivi contrattuali; correzione degli scostamenti.
Successo dei backup, andamento dello storage e tempi di ripristino su dashboard; report mensile + revisione annuale dell'architettura.
Non vendiamo nessuno strumento a sé stante. Progettiamo la sua architettura, spieghiamo quale strumento è giusto per ciascun livello e mostriamo in modo trasparente il costo totale di proprietà.
Negozio con 250.000 SKU cifrato venerdì alle 03:14; produzione completa ripristinata in 38 minuti dalla copia immutabile su Wasabi — zero ordini persi.
Uno sviluppatore ha cancellato una tabella in produzione; PostgreSQL PITR ha consentito un ripristino pienamente coerente in 4 minuti.
Un ospedale ha superato l'audit PHI di 7 anni; la completezza dei record nell'archivio immutabile è stata dimostrata matematicamente.
A un senior designer hanno rubato il laptop; i 2 TB di deliverable per i clienti erano off-site, con backup orari tramite Restic.
L'archivio di girato grezzo di un'emittente è passato a uno storage a livelli; S3 attivo + Glacier Deep Archive hanno portato un risparmio annuo del 63%.
Interruzione di AWS eu-central-1; failover automatico di DNS + database su eu-west-1 in 11 minuti, senza interrompere il traffico dei clienti.
No, uno snapshot da solo non è un backup. Uno snapshot è la «fotografia» di un disco o di un volume in un determinato istante e nella grande maggioranza dei casi risiede sullo stesso sistema di storage dei dati di produzione, spesso sullo stesso disco. Quindi, se si perdono i dati di produzione, si perde anche lo snapshot. Guasti hardware, blocchi dello storage, ransomware o errori di amministrazione colpiscono anche lo snapshot. Gli snapshot sono un ottimo primo livello per ripristini molto rapidi (si torna indietro in pochi secondi), ma per avere un vero backup lo snapshot deve essere copiato su un sistema separato, con un'identità separata e, idealmente, in un'area geografica separata. Nella nostra architettura lo snapshot è sempre un gradino — seguono il backup off-site, l'archivio immutabile e la replica di disaster recovery.
La regola 3-2-1 è la strategia di backup minima, collaudata da anni nel settore: tre (3) copie dei dati, su due (2) tipi di supporto diversi, con una (1) copia off-site. Una delle tre copie è la produzione stessa, due sono backup — così, se un backup è corrotto, c'è ancora l'altro. Due tipi di supporto proteggono dal guasto sistemico di una singola tecnologia (per esempio tutti gli SSD che cedono per un bug del firmware): disco + nastro, disco + object storage, NAS + cloud. La copia off-site protegge da incendi, alluvioni, furti, interruzioni regionali o sospensione dell'account — una copia nello stesso edificio, o anche nella stessa città, non conta come off-site. L'estensione moderna è «3-2-1-1-0»: una copia deve essere immutabile (1) e i test di ripristino devono dare zero (0) errori.
Solo se progettati correttamente. Il ransomware moderno resta nella rete per settimane prima di cifrare la produzione: scopre il sistema di backup, cancella o invalida i backup esistenti e poi cifra la produzione, così non resta nulla da ripristinare. Per questo gli account di backup devono essere indipendenti dalla directory di produzione, dall'SSO di produzione e persino dalla rete di produzione. La soluzione è lo storage WORM (write-once-read-many): S3 Object Lock in modalità Compliance, Wasabi Compliance, Veeam Hardened Repository, nastro air-gapped. Su questi livelli la cancellazione è matematicamente impossibile anche con privilegi di amministratore — per tutto il periodo di conservazione i dati sono «congelati». Nella nostra architettura ogni cliente ha almeno un livello WORM e il playbook di ripristino da ransomware viene verificato con esercitazioni.
Consigliamo almeno ogni tre mesi, ogni mese per i sistemi critici e test automatici settimanali negli ambienti regolamentati. Il ripristino di prova è l'unica dimostrazione che la sua architettura di backup funziona davvero — un «OK» nel log non basta. Un'esercitazione completa comprende il ripristino in una sandbox isolata, l'avvio dell'applicazione, la verifica dell'integrità del database e dei checksum, il confronto tra RPO/RTO misurati e obiettivi contrattuali. I test automatici, invece, creano dopo ogni backup una copia virtuale con «instant recovery», eseguono scansioni intelligenti e riportano il risultato. Per ogni cliente eseguiamo sia la verifica automatica settimanale sia l'esercitazione manuale trimestrale; i risultati vengono conservati in un report firmato — utile per audit, assicurazioni e rinnovi contrattuali.
Se progettato bene no, se progettato male può diventarlo parecchio. Il costo ha tre assi principali: storage (al mese per GB), egress (download durante il ripristino) e chiamate API (addebitate per ogni operazione sui file). L'approccio ingenuo, «mettiamo tutto su S3 ogni giorno, per intero», può costare decine di migliaia di dollari all'anno. L'approccio giusto è a livelli: gli ultimi 14 giorni, usati spesso, su S3 Standard, gli ultimi 90 giorni su S3 Standard-IA, l'ultimo anno su S3 Glacier Instant e il resto su Glacier Deep Archive — a parità di dati, il costo varia di 10-20 volte. Aggiungendo policy di ciclo di vita, compressione, deduplica e una strategia incremental forever, la spesa tipica dei nostri clienti per il backup in cloud si colloca intorno a poche centinaia di dollari al mese. Conoscere i propri scenari di ripristino è la chiave per il dimensionamento: Glacier Deep può essere ideale per chi ripristina una volta al mese, ma diventa rovinoso per chi ripristina 5 volte al giorno.
L'RPO (Recovery Point Objective) risponde alla domanda «quanta perdita di dati possiamo accettare?», l'RTO (Recovery Time Objective) alla domanda «in quanto tempo dobbiamo tornare operativi?». I due numeri nascono dall'analisi di impatto sul business: se quel sistema si ferma per un'ora o si perde un giorno di dati, qual è il costo reale in termini di ricavi, clienti e obblighi normativi? Nell'e-commerce i ricavi orari portano di solito l'RTO nell'ordine dei minuti: per un sistema che accetta ordini, 1 ora di RTO è troppo. Per un CRM a uso interno, un RTO di 8 ore può essere ragionevole. Per l'RPO: quanti minuti di attività aziendale può permettersi di perdere? Gli snapshot orari portano l'RPO a 60 minuti, la replica del transaction log lo riduce a pochi secondi. Questi obiettivi sono fissati nel contratto e dimostrati con misurazioni a ogni esercitazione — non sono numeri arbitrari, ma decisioni di business.
Sì, la nostra architettura è pienamente conforme a GDPR, KVKK, ISO 27001 Annex A.12.3, SOC 2 CC9 e PCI-DSS 9.5/12.10. Questo significa che: tutti i backup sono cifrati sia at-rest (AES-256) sia in-transit (TLS 1.3); le chiavi sono custodite in un KMS (AWS KMS, Azure Key Vault, HSM) con autorizzazioni separate da quelle del sistema di backup; i tempi di conservazione sono allineati agli obblighi di legge e, una volta superati, si procede a una cancellazione dimostrabile; per le richieste di «diritto all'oblio» esiste una procedura di ricerca nei backup e anonimizzazione selettiva; la localizzazione dei dati (Turchia/UE) è selezionabile; ogni accesso, ripristino e modifica di configurazione viene scritto in un audit log immutabile. Il pacchetto di preparazione all'audit comprende diagrammi di architettura, documenti di policy, matrice RACI e gli ultimi report delle esercitazioni — ogni domanda del revisore ha già una risposta pronta.
Sì, possiamo prendere in carico la sua installazione Veeam esistente (o Rubrik, Cohesity, Commvault, Acronis) così com'è; la licenza non cambia e l'hardware resta lo stesso. Nella prima settimana eseguiamo un audit completo: tasso di successo attuale dei backup, data dell'ultimo ripristino, policy di retention, stato dell'immutabilità, modello di accesso, gestione delle chiavi, monitoraggio e alert — documentiamo tutto e classifichiamo i rischi come rosso/giallo/verde. Nei 30 giorni successivi rivediamo l'architettura e, se necessario, aggiungiamo nuovi livelli in modalità bridge (vecchio + nuovo in parallelo); i dati non vengono spostati, si aggiungono nuove destinazioni di backup. Alla fine del terzo mese si esegue un'esercitazione di ripristino completa e si fissa la baseline. Abbiamo ingegneri certificati Veeam VMCE e Rubrik RCSA; non deve cambiare fornitore — portiamo la configurazione corretta e la disciplina operativa.
In un incontro gratuito di 30 minuti valutiamo insieme lo stato attuale dei suoi backup: obiettivi RPO/RTO, lacune di immutabilità, data dell'ultimo ripristino di prova e passi concreti per i prossimi 90 giorni — il tutto consegnato in un report scritto.
