Perché la velocità di backup USB crolla dopo i primi 50 GB di un unico trasferimento continuo?
La velocità del backup USB spesso crolla dopo decine di gigabyte, quando una cache veloce si riempie o il lavoro prolungato mette in evidenza un limite più lento dello storage, della temperatura o del percorso di trasporto.
I primi 50 GB non rappresentano una soglia universale. Sono un indizio del fatto che il trasferimento è passato dal comportamento a raffica a quello a regime, ha raggiunto un insieme di file diverso, ha riempito la cache di un SSD, ha attivato la pulizia SMR, ha riscaldato un enclosure o ha evidenziato ritrasmissioni USB. La diagnosi corretta confronta gli stessi dati sorgente tramite test controllati con file grandi e piccoli, registrando latenza della destinazione, temperatura, errori del collegamento e byte effettivamente scritti.
Conferma se il rallentamento segue i byte, il tempo o il numero di file
Ripeti un backup di dimensioni limitate registrando tempo trascorso, byte trasferiti, numero di file, dimensione media dei file, velocità di lettura della sorgente, velocità di scrittura della destinazione e punto esatto in cui il throughput diminuisce.
Fio distingue i carichi di lavoro sequenziali e casuali, rendendolo adatto a verificare se la destinazione rallenta dopo un volume fisso di byte o solo quando il backup raggiunge molti file piccoli.
Se il crollo si verifica vicino allo stesso numero di gigabyte scritti indipendentemente dalla combinazione di file, analizza i limiti della cache e della temperatura. Se segue il numero di file o la profondità delle directory, è più probabile che la causa sia legata ai metadati e al sovraccarico dell’applicazione.
Verifica se la cache burst di un SSD si è riempita
Identifica il supporto di destinazione e registra modello, spazio libero, temperatura, firmware e comportamento di scrittura prolungata. Confronta la velocità del primo minuto con quella dopo il rallentamento.
Crucial spiega che le prestazioni di un SSD possono diminuire quando la garbage collection in background richiede tempo per la pulizia, motivo per cui una breve raffica veloce non rappresenta la velocità di scrittura del drive su lunga durata.
Sospendi il carico abbastanza a lungo da consentire al drive di raffreddarsi e completare la pulizia in background, quindi riprendi usando gli stessi dati. Un recupero temporaneo supporta l’ipotesi di pressione sulla cache o sulla temperatura, ma senza dati su temperatura e latenza non permette di distinguere le due cause.
Escludi la pulizia SMR gestita dal drive
Verifica se la destinazione USB contiene un disco SMR gestito dal drive. Confronta un singolo flusso sequenziale di grandi dimensioni con un backup che aggiorna o crea ripetutamente molti file piccoli.
Seagate afferma che gli SMR offrono le prestazioni migliori con scritture prevedibili, mentre gli aggiornamenti frammentati o casuali possono creare ulteriori spostamenti interni e una velocità a regime inferiore.
Non dedurre la presenza di SMR solo dalla capacità o dal marchio. Conferma il modello esatto ed evita di usare un drive le cui caratteristiche di carico siano incompatibili con backup incrementali frequenti o ricchi di operazioni sui metadati.
Controlla reset USB, autosospensione e ritrasmissioni del collegamento
Salva il log dell’host dal momento precedente all’avvio del backup fino al rallentamento. Cerca reset del dispositivo, errori UAS, annullamenti dei comandi, variazioni della velocità negoziata, disconnessioni e transizioni di autosospensione.
Il kernel Linux documenta la gestione dell’alimentazione USB in fase di esecuzione, aiutando a distinguere un rallentamento del supporto di archiviazione da un percorso di trasporto che, sotto carico prolungato, si sospende, riprende o reimposta ripetutamente.
Un collegamento USB può rimanere connesso mentre le ritrasmissioni riducono il throughput utile. Prova una porta posteriore diretta, un cavo corto sicuramente funzionante, l’alimentatore corretto e un altro host prima di modificare il filesystem o le impostazioni del backup.
Determina se il backup passa a un carico di lavoro con file piccoli
Esamina il log del backup in corrispondenza del rallentamento e confronta dimensione media dei file, frequenza di creazione, operazioni sui metadati, gestione degli ACL, checksum, compressione e cifratura prima e dopo la soglia.
Red Hat descrive lo storage con file piccoli come un carico di lavoro intensivo sui metadati, quindi un valore inferiore in MB/s può essere normale quando il backup passa da file di dati grandi a numerose operazioni di creazione, chiusura, stat e aggiornamento delle directory.
Misura i file al secondo oltre ai megabyte al secondo. Una fase con file piccoli può mostrare un throughput in byte ridotto mentre lo stack di archiviazione rimane occupato e reattivo.
Verifica spazio libero, discard e amplificazione delle scritture
Registra lo spazio libero sulla destinazione, la conservazione degli snapshot, l’uso del cestino, l’allocazione thin e se il discard raggiunge un SSD attraverso il bridge USB e il filesystem.
Il manuale di fstrim spiega che i blocchi inutilizzati devono essere comunicati allo storage compatibile prima di poter essere riutilizzati in modo efficiente.
Non abilitare il discard attraverso un enclosure che non lo inoltri in modo sicuro. Ripristina innanzitutto un margine adeguato di spazio libero, quindi confronta lo stesso segmento di backup dopo una pulizia supportata.
Esegui un backup A/B controllato prima di sostituire l’hardware
Crea un set di test con file grandi e uno con file piccoli della stessa dimensione complessiva. Esegui entrambi sulla stessa destinazione dopo il raffreddamento, quindi ripeti su un altro percorso USB o un’altra destinazione registrando temperatura ed errori.
La guida di ZimaSpace alla preparazione di un backup iniziale di grandi dimensioni fornisce il metodo complementare per separare la pianificazione del backup e la saturazione della rete dalle prestazioni a regime della destinazione.
La diagnosi è completa quando il rallentamento segue una condizione misurabile — esaurimento della cache, pulizia SMR, combinazione di file, calore, ritrasmissioni USB o poco spazio riutilizzabile — e il percorso corretto mantiene la velocità a regime prevista.
Domande frequenti
Un rallentamento dopo 50 GB dimostra che il drive ha una cache da 50 GB?
No. La soglia può riflettere anche il tempo trascorso, la temperatura, la combinazione di file, la pressione sullo spazio libero o la pulizia interna. Ripeti il test con dati di forma diversa prima di stimare la dimensione della cache.
Perché mettere in pausa il backup ripristina temporaneamente la velocità?
La pausa può consentire a un SSD di trasferire i dati dalla cache, a un disco SMR di riorganizzare le scritture, a un enclosure di raffreddarsi oppure al trasporto USB di recuperare. Per distinguerli sono necessari log di temperatura e latenza.
Devo valutare le prestazioni del backup in base alla velocità iniziale?
No. La pianificazione della capacità dovrebbe usare la velocità stabile dopo il riempimento delle cache e quando il carico raggiunge la combinazione normale di dati, metadati, verifica e attività di conservazione.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
