Dove resta il file che un visitatore carica sul tuo sito

Se un visitatore carica un file sul sito e poi una seconda macchina deve mostrarlo, la domanda è dove quel file resta, quale copia lo include, e con quale indirizzo si ritrova. Il 3 novembre 2026 ho letto la pagina sulla macchina condivisa, la pagina sulle copie, la pagina sul disco che non scrive, due pagine del 2017 sui processi e sui servizi, e sei pagine di AWS. Non dicono la stessa cosa. Non ho caricato un file e non ho misurato una macchina.

Le pagine già online

La pagina sulla macchina risponde a chi divide l'host con il sito. Due forme restano le sue parole: quota virtualizzata su un host condiviso, e macchina fisica con isolamento hardware. Non nomina un file caricato, un deposito di oggetti, né l'indirizzo con cui quel file si rivede. Non la riscrivo. Chi divide con te la macchina su cui sta il tuo sito. La risposta letta il 3 novembre 2026 porta la data 06:57:25 GMT. In pagina la data è 3 novembre 2026. Non le unisco.

La pagina sulle copie risponde a che cosa resta se il sito va riaperto. Nello stesso elenco della guida che cita, due frasi dopo una nota sullo storage immutabile, nomina lo storage a oggetti fra le risorse da proteggere, insieme allo storage di database e ad altri due esempi. Protezione dalla cancellazione e blocco degli oggetti restano due cose, e il controllo di versione è un'altra frase di quella guida. Sono frasi sulla copia e sulla protezione. Non dicono se il file che il visitatore ha caricato vive sul disco della macchina o in un contenitore. Non la riscrivo. Che cosa resta del tuo sito se devi riaprirlo. La risposta letta il 3 novembre 2026 porta la data 06:57:25 GMT, lo stesso secondo della pagina sulla macchina. In pagina la data è 3 novembre 2026. Non le unisco.

La pagina sul disco che non scrive elenca sessioni, file caricati, log e aggiornamenti come domanda, e dice che le pagine dei comandi non nominano un file caricato. Non decide se quel file deve stare sul disco della macchina o altrove. Non la riscrivo. Come capire se il disco del tuo sito non può più scrivere. La risposta letta il 3 novembre 2026 porta la data 06:57:26 GMT, un secondo dopo le due pagine precedenti. Non lo unisco a quel secondo.

Il disco del processo non è il posto che resta

La pagina Processes non ha last-modified. In pagina scrive Last updated 2017, e in chiusura un copyright 2026. La risposta letta il 3 novembre 2026 porta la data 06:58:21 GMT. Il 2017, il 2026 e le 06:58 non sono lo stesso orario. Non li unisco. Indirizzo: https://12factor.net/processes.

Dice che l'applicazione gira come uno o più processi senza stato, e che quei processi non condividono nulla. La pagina usa la parola share-nothing. Qualunque dato che deve restare va in un servizio con stato, di solito una base dati. Disco del processo e base dati sono già due posti, in due frasi. Non li unisco.

La memoria o il filesystem del processo si possono usare come cache breve, di una sola operazione. L'esempio è scaricare un file grande, lavorarci, e mettere il risultato nella base dati. È l'esempio della cache. Non è la frase che dice dove resta il file caricato da un visitatore. Non lo trasformo in quella frase.

La pagina dice che l'applicazione non assume mai che ciò che sta in memoria o su disco sarà disponibile a una richiesta o a un lavoro futuri. Con molti processi di ogni tipo, è alta la probabilità che la richiesta dopo sia servita da un processo diverso. Anche con un solo processo, un riavvio di solito cancella tutto lo stato locale, memoria e filesystem. Le cause che la pagina mette in quella frase sono tre: un deploy del codice, un cambio di configurazione, o l'ambiente che sposta il processo su un'altra macchina fisica. Molti processi, un solo processo, e le tre cause, restano nella stessa pagina ma non sono una sola conseguenza. Non le unisco. Il di solito del riavvio non è una misura che ho fatto su un sito.

Più sotto, i programmi che impacchettano le risorse usano il filesystem come cache dei file compilati. La pagina preferisce farla durante la fase di build. È la frase sui file compilati. Non è il file che un visitatore carica. Non la uso per quel file.

Un'altra frase parla delle sessioni appiccicose: tenere i dati di sessione nella memoria del processo e aspettarsi che le richieste dello stesso visitatore tornino allo stesso processo. La pagina dice che sono una violazione e che non vanno usate. I dati di sessione, dice, stanno bene in un deposito con scadenza, e fa due esempi. È la sessione. Non è il file caricato. Non li unisco.

Il servizio esterno è un'altra pagina, un secondo dopo

La pagina Backing services non ha last-modified. Anche questa scrive Last updated 2017, e lo stesso copyright 2026. La risposta letta il 3 novembre 2026 porta la data 06:58:22 GMT, un secondo dopo la pagina dei processi. Non unisco il secondo. Indirizzo: https://12factor.net/backing-services.

Un servizio di supporto è qualunque servizio che l'applicazione consuma in rete durante il lavoro normale. Il primo elenco fa quattro esempi: basi dati, code, posta in uscita, cache. Un'altra frase, sui servizi di terzi, include i servizi di file binari, e l'esempio è Amazon S3. Il primo elenco e l'esempio del deposito di oggetti non sono la stessa frase. Non li unisco.

Il codice non distingue un servizio locale da uno di terzi. Per l'applicazione sono risorse agganciate, raggiunte con un indirizzo oppure con un altro localizzatore o con credenziali, tenuti nella configurazione. Quell'indirizzo è il modo in cui l'applicazione raggiunge il servizio. Non è, da solo, l'indirizzo con cui un visitatore rivede il file. Non li unisco.

L'esempio dello scambio è una base dati locale sostituita da una di terzi senza cambiare il codice, e lo stesso per la posta. Un altro esempio, se la base dati va male per un problema hardware, è avviare un server nuovo ripristinato da una copia recente, staccare la base dati di produzione e agganciare la nuova, senza cambiare il codice. È la copia della base dati. Non è la copia del file caricato, e non è la frase delle versioni che sta su un'altra pagina. Non li unisco.

Il deposito di oggetti, sulla pagina di benvenuto

La pagina What is Amazon S3 ha last-modified 2 novembre 2026 alle 22:18:17 GMT. La risposta letta il 3 novembre 2026 porta la data 06:54:45 GMT, e un Age di 217 secondi. Il 2 novembre alle 22:18, le 06:54 e i 217 secondi non sono lo stesso orario. Non li unisco. Indirizzo: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html.

Dice che Amazon S3 è un servizio di storage a oggetti. Un elenco di casi d'uso include, tra gli altri, i siti web e il backup con ripristino. Sono voci di uno stesso elenco. Una voce non dice che il file caricato sul sito sta in quel servizio, e non dice che la copia del sito è quel servizio. Non le unisco.

In un'altra frase dice che si può usare il versioning per tenere più versioni di un oggetto nello stesso contenitore, e così ripristinare oggetti cancellati o sovrascritti per errore. È la frase di questa pagina. La pagina dedicata alle versioni, più sotto, non la copio qui.

Dice che i contenitori e gli oggetti che contengono sono privati. Si ha accesso solo alle risorse che si creano. Per concedere permessi più fini, o per controllarli, elenca delle funzioni. La prima è il blocco dell'accesso pubblico: di default è acceso a livello di contenitore. La pagina raccomanda di lasciarlo acceso, salvo che si sappia di doverne spegnere uno o più per un caso preciso. Privato, solo le risorse create, blocco acceso di default, e la raccomandazione, sono frasi vicine. Non le riduco a un solo interruttore.

Sulla coerenza, la pagina dice che Amazon S3 dà coerenza forte di lettura dopo la scrittura, in tutte le regioni, per le richieste che scrivono un oggetto e per quelle che lo tolgono. Vale sia per la scrittura di un oggetto nuovo, sia per la scrittura che sovrascrive un oggetto esistente, sia per la rimozione. In più, le letture su alcuni elenchi, sulle liste di controllo, sulle etichette e sui metadati dell'oggetto sono fortemente coerenti. La pagina fa l'esempio della lettura dei metadati. Non ho aperto la pagina del modello di coerenza a cui rimanda. Non ne descrivo il resto. Non copio i nomi dei metodi.

Un oggetto si indica in modo univoco dentro un contenitore con una chiave, il nome. Ogni oggetto ha esattamente una chiave. La combinazione di contenitore, chiave e, se il versioning è acceso, identificativo di versione, identifica ciascun oggetto. La pagina dice che si può pensare a S3 come a una mappa fra contenitore, chiave e versione, e l'oggetto. Ogni oggetto si può indirizzare con la combinazione di endpoint del servizio, nome del contenitore, chiave e, in opzione, una versione.

L'esempio di indirizzo, sulla stessa pagina, è https://amzn-s3-demo-bucket.s3.us-west-2.amazonaws.com/photos/puppy.jpg. Il nome del contenitore è quello scritto prima del punto, e la chiave è la parte finale. L'esempio non mostra un identificativo di versione. L'indirizzo di esempio, e la frase che la versione è opzionale, non sono la stessa riga. Non li unisco. Non ho aperto quel nome. Non è un sito misurato.

La pagina degli oggetti non ha un solo massimo

La pagina Amazon S3 objects overview ha last-modified 2 novembre 2026 alle 22:18:40 GMT, ventitré secondi dopo la pagina di benvenuto. La risposta letta il 3 novembre 2026 porta la data 06:58:23 GMT. Non unisco le 22:18:40 con le 06:58:23, né con le 22:18:17 dell'altra pagina. Indirizzo: https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingObjects.html.

Dice che gli oggetti si mettono in uno o più contenitori, e che ciascun oggetto può arrivare fino a 50 TB. Più sotto, nel valore, dice che un oggetto può essere qualunque sequenza di byte, e che la dimensione va da zero a 50 TB. Fino a 50 TB, e da zero a 50 TB, sono due frasi. Non le unisco.

Una nota, subito dopo, dice che la documentazione di solito cita il limite di 50 TB, mentre il massimo effettivo è 53,7 TB, scritti sulla pagina come 53.7 TB, pari a 48.8 TiB. La nota attribuisce quel limite ai vincoli del caricamento in parti: al massimo 10000 parti da 5 GiB, e scrive il prodotto come 50000 GiB, cioè 53.7 TB. Il 50 TB citato di solito, il massimo della nota, e il prodotto delle parti, sono tre scritti. Non li riduco a un solo numero, e non li uso come misura di un file.

La chiave, su questa pagina, è il nome che si assegna all'oggetto e con cui lo si recupera. L'identificativo di versione è una stringa che Amazon S3 genera quando si aggiunge un oggetto. Dentro un contenitore, chiave e versione insieme identificano l'oggetto. Nome assegnato da chi carica, e stringa generata dal servizio, sono due frasi. Non le unisco.

Le versioni non sono la copia della base dati

La pagina sul versioning ha last-modified 2 novembre 2026 alle 22:18:18 GMT. La risposta letta il 3 novembre 2026 porta la data 06:58:24 GMT. Un secondo dopo la pagina degli oggetti, e un secondo dopo le 22:18:17 della benvenuto rispetto a questo last-modified. Non li unisco. Indirizzo: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html.

Il versioning è un modo per tenere più varianti di un oggetto nello stesso contenitore. Si possono preservare, recuperare e ripristinare tutte le versioni di ogni oggetto. Con il versioning si recupera più facilmente da azioni non volute e da guasti dell'applicazione. Sono due frasi: tutte le versioni, e il recupero da azioni non volute o da guasti. Non le unisco. Non sono la voce backup e ripristino dell'elenco sulla pagina di benvenuto, e non sono la copia della base dati della pagina del 2017.

Dopo che il versioning è acceso per un contenitore, se arrivano più scritture simultanee per lo stesso oggetto, la pagina dice che le memorizza tutte. I contenitori con versioning acceso aiutano a recuperare oggetti da una cancellazione accidentale o da una sovrascrittura. L'esempio: se si toglie un oggetto, Amazon S3 inserisce un segnaposto invece di rimuoverlo per sempre. Il segnaposto diventa la versione corrente. Se si sovrascrive un oggetto, nasce una versione nuova. Si può sempre ripristinare la versione precedente. Segnaposto, versione nuova, e ripristino della precedente, sono tre frasi. Il sempre sta in questo paragrafo, sui contenitori con versioning acceso. Non l'ho letto sulla pagina dei contenitori senza versioning, né su quella in cui il versioning è sospeso. Non le descrivo.

L'indirizzo non è uno solo

La pagina sull'accesso a un contenitore generico ha last-modified 2 novembre 2026 alle 22:18:36 GMT. La risposta letta il 3 novembre 2026 porta la data 06:58:24 GMT, lo stesso secondo della pagina sul versioning, e un last-modified diverso. Non li unisco. Indirizzo: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-bucket-intro.html.

Dice che si accede ai contenitori generici con la console, con la riga di comando, con i kit di sviluppo, o con l'API. Ogni metodo copre casi d'uso specifici. Sono quattro vie. Non ne faccio un solo pulsante, e non copio i nomi dei comandi.

Fra i casi d'uso c'è il sito statico: si può configurare il contenitore perché funzioni come un sito. Una nota, in quel caso, dice che Amazon S3 supporta sia gli indirizzi in stile virtual-hosted sia gli indirizzi in stile path, per l'accesso al sito statico. Perché i contenitori si raggiungono in entrambi gli stili, raccomanda nomi di contenitore compatibili con il DNS. I due stili sono la nota del sito statico. Non sono l'esempio di indirizzo della pagina di benvenuto, che sta su un'altra pagina e in quella riga non è chiamato sito statico. Non li unisco. L'indirizzo nella configurazione, sulla pagina del 2017, è un terzo posto: è il localizzatore con cui l'applicazione raggiunge il servizio. Non è, da solo, uno dei due stili.

Il volume agganciato alla macchina

La pagina dei volumi EBS, all'indirizzo vecchio, ha risposto 301 il 3 novembre 2026 alle 06:58:23 GMT, con Age 6, verso https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html. La risposta finale porta la data 06:54:26 GMT, Age 243, e last-modified 3 novembre 2026 alle 01:09:13 GMT. Il 301, la data finale, l'Age e l'01:09 non sono lo stesso orario. Non li unisco. Ho letto il corpo della risposta finale.

Un volume EBS è un dispositivo di storage a blocchi, durevole, che si può agganciare alle istanze. Dopo l'aggancio, lo si usa come un disco fisico. I volumi restano indipendentemente dalla vita in esecuzione di un'istanza. Vita in esecuzione dell'istanza, e riavvio che di solito cancella il filesystem del processo, sono due pagine. Non dico che il volume cancelli il file, e non dico che il filesystem del processo resti perché il volume resta. Non li unisco.

Si possono agganciare più volumi a una sola istanza. Volume e istanza devono stare nella stessa zona di disponibilità. A seconda dei tipi di volume e di istanza, si può usare Multi-Attach per montare un volume su più istanze allo stesso tempo. Più volumi su una istanza, stessa zona, e un volume su più istanze solo per alcuni tipi, sono tre frasi della stessa pagina. Non le unisco in un disco sempre condiviso, né in un disco sempre di una sola macchina.

La pagina dice anche che si possono usare i volumi come storage primario per dati che cambiano spesso, e fa due esempi: il disco di sistema di un'istanza, o lo storage di un'applicazione di base dati. Sono gli esempi della pagina. Non sono il file caricato da un visitatore. Non li assegno a quel file.

Multi-Attach è una pagina più stretta

La pagina Multi-Attach, all'indirizzo vecchio, ha risposto 301 il 3 novembre 2026 alle 06:58:24 GMT, verso https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes-multi.html. La risposta finale porta la data 06:58:27 GMT e last-modified 3 novembre 2026 alle 01:09:17 GMT, quattro secondi dopo l'01:09:13 della pagina dei volumi. Non unisco i quattro secondi, né le 06:58:24 del 301 con le 06:58:27 del corpo. Ho letto il corpo finale.

Dice che Multi-Attach permette di agganciare un solo volume di tipo Provisioned IOPS SSD, io1 oppure io2, a più istanze nella stessa zona di disponibilità. Ogni istanza a cui il volume è agganciato ha permesso pieno di lettura e di scrittura sul volume condiviso. La pagina dei volumi diceva a seconda dei tipi. Questa pagina nomina io1 o io2. Non le unisco in una sola regola per ogni disco.

Una nota dice che i file system ordinari, e fa gli esempi XFS ed EXT4, non sono progettati per essere usati nello stesso momento da più server, come le istanze. Per i carichi di produzione bisognerebbe usare un file system clustered, così i dati restano resilienti e affidabili. File system ordinario, e file system clustered, sono due frasi. Non dico che un volume agganciato a due macchine sia già un disco condiviso sicuro. Non copio una procedura.

La stessa pagina dice che i volumi io1 e io2 con Multi-Attach acceso supportano il fencing dell'input e dell'output. Quei protocolli controllano la scrittura in uno storage condiviso per tenere i dati coerenti. È un'altra frase. Non la trasformo in un comando.

Non sono la stessa frase

Sulla pagina dei processi il filesystem è una cache breve. La richiesta dopo può arrivare a un altro processo. Un riavvio, di solito, cancella lo stato locale. La sessione appiccicosa è un altro paragrafo, e non è il file caricato.

Sulla pagina dei servizi il deposito di oggetti è un esempio di servizio di file binari, raggiunto come le altre risorse. La copia di cui parla quell'esempio è una base dati ripristinata e riagganciata. Non è il file del visitatore.

Sulla pagina di benvenuto di S3 l'oggetto si indirizza con contenitore e chiave, l'esempio non mostra la versione, e i contenitori sono privati con il blocco pubblico acceso di default. Il 50 TB della pagina degli oggetti, il da zero a 50 TB, e il 53.7 TB della nota, restano tre scritti. Le versioni, quando sono accese, tengono le varianti e mettono un segnaposto al posto della rimozione definitiva. Non sono la copia della base dati.

Sulla pagina dei volumi il volume resta oltre la vita in esecuzione dell'istanza, nella stessa zona, e il montaggio su più istanze dipende dai tipi. Sulla pagina Multi-Attach quei tipi sono io1 o io2, e un file system ordinario non è fatto per più server insieme. Non ricavo da queste pagine un posto unico per ogni file caricato.

Esempio ipotetico

bottega.example è un nome di scuola. Non l'ho aperto. Non so se il file che un visitatore vi carica sta sul disco di un processo, su un volume agganciato a una macchina, o in un contenitore di oggetti. prova.bottega.example è l'altro nome. Non l'ho aperto. Non so se la richiesta dopo arriva lì, né se i due nomi condividono un volume, né quale indirizzo mostrerebbe il file.

Non assegno a questi nomi 50 TB, zero byte, 53.7 TB, 48.8 TiB, diecimila parti o 5 GiB. Non assegno un segnaposto di versione, un blocco dell'accesso pubblico, una zona di disponibilità, io1, io2, né uno dei due stili di indirizzo. I numeri e i tipi restano quelli delle pagine lette.

Che cosa questa pagina lascia stare

Non ho caricato un file. Non ho aperto la pagina del modello di coerenza oltre il rinvio, né le pagine dei contenitori senza versioning o con versioning sospeso. Non ho copiato i nomi dei comandi. La copertina è nuova, perché la pagina è nuova.

Non ho riscritto la pagina sulla macchina, la pagina sulle copie, la pagina sul disco, la pagina sulla rotazione della chiave, la pagina sul timer, la pagina sul primo byte, la pagina sugli spostamenti, la pagina sulle misure, la pagina su Server-Timing, la mappa di DNS, hosting e CDN, la pagina sulla connessione lunga, la pagina sul lavoro lungo, la pagina sulla copia di prova, la pagina sulla chiave, la pagina sulla compressione, la pagina sulla cartella e la pagina sul lucchetto. Le mappe del codice sorgente non sono questa pagina. Non le ho scritte.

Fonti lette il 3 novembre 2026. Pagine già online, non riscritte: la macchina, risposta delle 06:57:25 GMT. Le copie, risposta delle 06:57:25 GMT. Il disco, risposta delle 06:57:26 GMT. Processes, senza last-modified, Last updated 2017 in pagina, risposta delle 06:58:21 GMT, https://12factor.net/processes. Backing services, senza last-modified, Last updated 2017 in pagina, risposta delle 06:58:22 GMT, https://12factor.net/backing-services. Amazon S3, benvenuto, last-modified 2 novembre 2026 alle 22:18:17 GMT, risposta delle 06:54:45 GMT con Age 217, https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html. Oggetti, last-modified alle 22:18:40 GMT, risposta delle 06:58:23 GMT, https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingObjects.html. Versioning, last-modified alle 22:18:18 GMT, risposta delle 06:58:24 GMT, https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html. Accesso al contenitore, last-modified alle 22:18:36 GMT, risposta delle 06:58:24 GMT, https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-bucket-intro.html. Volumi EBS, 301 delle 06:58:23 GMT, risposta finale delle 06:54:26 GMT con Age 243, last-modified 3 novembre 2026 alle 01:09:13 GMT, https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html. Multi-Attach, 301 delle 06:58:24 GMT, risposta finale delle 06:58:27 GMT, last-modified alle 01:09:17 GMT, https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes-multi.html.