Home » Oltre 390 TB di storia del gaming a rischio: la crisi dei chip colpisce Myrient

Oltre 390 TB di storia del gaming a rischio: la crisi dei chip colpisce Myrient

Tempo di lettura: 4 minuti

Oltre 390 TB di storia del gaming a rischio: la crisi dei chip colpisce Myrient

Myrient, uno dei più grandi archivi online dedicati alla preservazione di videogiochi (circa 390 TB di dati), chiuderà il 31 marzo 2026 perché non riesce più a sostenere i costi di infrastruttura e hardware, esplosi anche a causa della domanda di chip per l’IA.[1][2][3][4]

Cosa sta succedendo a Myrient

  • Chiusura annunciata per il 31 marzo 2026, con l’intero archivio che verrà messo offline.[1][2][3][4]
  • Collezione di circa 390 TB di giochi (soprattutto retro / Nintendo e classici) accumulati dal 2022 con finalità di preservazione.[2][3][4]
  • Modello senza pubblicità, senza registrazione, con download veloci e illimitati, finanziato solo da donazioni che però sono rimaste piatte.[2][4]

Perché la crisi dei chip lo sta uccidendo

  • Il gestore dichiara costi di hosting e server oltre i 6.000 dollari al mese di tasca propria, diventati insostenibili.[1][2][3]
  • Aumento dei prezzi di RAM, SSD e HDD legato in buona parte all’enorme domanda per data center e infrastrutture IA, che rende molto più caro archiviare e fare caching di centinaia di terabyte.[1][2][3][5]
  • Per continuare a reggere il traffico sarebbero necessari upgrade allo storage e alla cache che il gestore non può più permettersi.[1][3]

Altri fattori critici (oltre ai chip)

  • Download manager “aggressivi” che saturano la banda, aggirano la pagina donazioni e aumentano il consumo di risorse senza contribuire ai costi.[6][1][3][4]
  • Traffico in forte crescita, ma entrate ferme: più utenti, più carico, stessi (pochi) soldi in ingresso.[2][3][4]
  • La combinazione di uso scorretto da parte di parte dell’utenza e rincari hardware/hosting ha reso il progetto non più sostenibile: il fondatore afferma esplicitamente che “non può più permettersi” di gestirlo.[1][2]

Impatto sulla preservazione della storia del gaming

  • Se non verrà duplicato altrove, rischia di andare perso uno degli archivi più grandi di giochi classici e immagini disco, con effetti pesanti sulla preservazione soprattutto delle piattaforme più vecchie e di titoli meno noti.[2][3][7][4]
  • Comunità di data hoarder e appassionati si stanno già organizzando per scaricare il più possibile dei 390 TB e ricaricarli su altre piattaforme, tracker privati o Internet Archive per evitare la perdita totale.[8][7]

Cosa significa in pratica per gli utenti

  • Fino al 31 marzo 2026 è teoricamente possibile scaricare ancora dal sito, nei limiti della banda e delle risorse disponibili.[2][3][4]
  • Dopo lo shutdown, l’accesso diretto a Myrient sparirà; l’unica speranza saranno mirror comunitari, backup condivisi e nuovi progetti di preservazione nati sulla sua eredità.[2][8][7][4]

Ti interessa di più l’aspetto “preservazione” (come salvare il contenuto ora) o l’aspetto “infrastruttura/costi” (come sarebbe potuto rimanere sostenibile tecnicamente)?

Mi interessa il modello infrastrutturale e i possibili workaround

Per un archivio come Myrient il collo di bottiglia è un mix di storage “bulk” economico, caching aggressiva su RAM/SSD e banda enorme; i workaround sostenibili ruotano tutti intorno a ridurre banda diretta e CAPEX spalmando costi sulla community.[1][2][3][4][5]

Modello infrastrutturale di Myrient (semplificato)

  • Decine di server con centinaia di TB su HDD (oltre 400 TB dichiarati in passato) con backend unificato per i contenuti.[1][4]
  • Layer di cache su RAM/SSD per reggere directory listing e download concorrenti, sempre più costosi con l’aumento dei prezzi di memoria.[2][5]
  • Banda complessiva dell’ordine delle decine di Gbit/s (30–40 Gbit/s, con ~5 PB/mese di traffico), dove la voce di costo principale è proprio la banda uscente continuativa.[1]
  • Backup offsite “cold” separati per DB e parti del frontend, quindi ulteriore storage anche se meno costoso (minor I/O, niente banda massiva).[4]

In pratica: grande pool HDD “lento” + cache veloce + molti Gbit/s verso Internet, con costi mensili >6.000 dollari solo di differenza non coperta dalle donazioni.[2][3][6][5]

Perché questo modello è esploso

  • Prezzi di RAM, SSD e HDD in forte salita da fine 2025 per domanda IA/datacenter, che aumentano sia l’OPEX (hosting) sia il costo di ogni upgrade necessario.[2][3][7][5]
  • Necessità di espandere cache/storage per mantenere performance con traffico in crescita, ma senza crescita proporzionale delle entrate.[2][6][5]
  • Download manager e scraper che saturano la banda, vanificano eventuali “soft limit” e fanno esplodere il consumo di throughput senza portare entrate aggiuntive.[8][9][2][7]

Con 4–5 PB/mese di traffico servito, ogni piccolo aumento di costo per TB o per Mbps impegnato diventa devastante se non c’è un modello di monetizzazione più robusto.[1][2]

Workaround tecnici possibili (a livello di architettura)

Questi sono pattern generali che avrebbero potuto mitigare i costi, non “soluzioni magiche”.

  • Spostare il grosso del traffico su reti P2P/private tracker
  • Usare seedbox/servers solo come “seed origin” e far distribuire il bulk dati via BitTorrent o simili; c’è chi ha stimato, ad esempio, ~17 seedbox da 24 TB con 10 Gbit/s con costo complessivo intorno a 850 €/mese come alternativa più scalabile alla pura banda in uscita centralizzata.[8][10]
  • Accesso tramite tracker privato con login per ridurre scraping e abusi massivi, mantenendo comunque un archivio sempre seedato da più peer.[8][10]
  • Ridurre l’esposizione HTTP “grezza”
  • Limitare protocolli “comodissimi ma costosi” (FTP/rsync sono stati infatti progressivamente rimossi proprio per costi di banda e manutenzione).[4]
  • Implementare rate limiting/IP reputation e limitazione connessioni parallele per frenare download manager aggressivi senza penalizzare troppo l’utente normale.[9][2]
  • Caching più selettiva e multi-tier
  • Tenere in cache SSD solo i titoli effettivamente hot (LRU/ARC o analogo) e usare HDD puri per il resto, riducendo la quantità di SSD richiesta.[2][5]
  • Valutare cold storage ancora più economico per bundle poco scaricati (dischi lenti, tape, storage nearline), spostandoli su storage caldo solo quando richiesti.[10]
  • Architettura ibrida multi-cloud / colo
  • Usare provider diversi (per es. seedbox per il bulk, un DC con buona peering per la parte web/API, storage nearline per backup) invece di “un grosso contratto unico” ad alta banda.[10][1]
  • Sfruttare CDN solo per metadata/cover/asset piccoli (non per le ISO), per alleggerire il carico dei server principali.[1][2]

Ovviamente questi workaround spostano parte del peso sulla community (seed, hosting mirror, ecc.) e introducono più complessità operativa.

Workaround lato modello di servizio

Non sono puramente tecnici, ma impattano direttamente sull’architettura sostenibile.

  • Accesso controllato
  • Registrazione obbligatoria, limiti giornalieri o per connessione, magari con whitelist per “power user” affidabili, riduce l’impatto di scraper e rivenditori.[8][9]
  • “Soft ratio” o incentivi a chi offre banda come seeder/host, in stile private tracker classico, per distribuire i costi di banda.[8][10]
  • Riduzione qualità del servizio free
  • Ridurre velocità di download di default e offrire slot più veloci solo a chi contribuisce (donazioni o seed/banda condivisa).[1][2]
  • Finestra temporale per download (es. maintenance, limitazioni nelle ore di picco) per evitare picchi ingestibili senza overprovisioning costante.[1]
  • Diversificazione dei costi di storage
  • Migrare i contenuti rarissimi ma poco scaricati su supporti tipo LTO offsite (archivio “deep”) e lasciare su storage online solo il catalogo effettivamente richiesto.[10]

Cosa copieresti/eviteresti se progettassi “Myrient 2.0”

Da copiare: backend unificato, forte automazione dei mirror/backup, e un layer di cache ben dimensionato sopra HDD bulk; da evitare: niente controllo sugli scaricatori aggressivi, nessuna barriera di ingresso per chi satura banda e zero distribuzione dei costi di rete sulla community.[1][2][6][4][5]

Se volessimo ragionare più in concreto su una possibile architettura alternativa, ti interessa un modello “legale” con solo preservazione metadata o un modello realistico in stile private tracker/distribuzione P2P?

\ Get the latest news /

5 1 voto
Valutazione dell'articolo
Iscriviti
Notificami
guest
0 Commenti
Vecchi
Più recenti Le più votate
Feedback in linea
Visualizza tutti i commenti
PAGE TOP
0
Esprimete la vostra opinione commentando.x
×