Et webhotell kan stoppe nye filer selv om kontrollpanelet viser ledige gigabyte. Årsaken kan være en egen grense for antall filer, mapper eller andre filsystemobjekter, ofte omtalt som inodes.

Det motsatte kan også skje: nettstedet har få filer, men store bilder, video, backup eller databasefiler fyller diskkvoten. Du må derfor måle minst to ting hver for seg:

  1. brukt og ledig lagringsplass
  2. brukt og tillatt antall filer/inodes

Ikke start med tilfeldig sletting. Et cacheområde, en backupmappe og en aktiv opplastingsmappe kan se like «store» ut, men skal håndteres på helt forskjellige måter.

Hva er en inode?

På vanlige Unix-lignende filsystemer har en fil en inode med metadata som eier, rettigheter, tidsstempler og hvor dataene finnes. Linux-manualen for inodes beskriver dette mer presist.

For en webhotellkunde er den praktiske modellen:

  • mange filer og mapper bruker mange filoppføringer
  • én stor fil bruker mye disk, men normalt få oppføringer
  • mange svært små filer kan bruke lite synlig data og likevel nå filgrensen

«Én fil er alltid én inode» er en nyttig forenkling, men ikke en komplett filsystemregel. Hard links kan dele inode, og leverandørens kontrollpanel kan telle på en annen måte enn operativsystemet. Noen plattformer bruker objektlagring og snakker om objekter eller filantall i stedet for inodes.

Be derfor om leverandørens egen definisjon og målemetode når en kvote skal sammenlignes.

Diskkvote, filantall og andre grenser

GrenseMålerVanlig symptom
Diskplassallokert eller fakturert datamengdeopplasting, backup eller database kan ikke vokse
Inodes/filantallfiler, mapper og eventuelle andre objekternye små filer, økter eller cacheoppføringer feiler
Databasekvotedatabasens størrelse eller antall databaserlagring og spørringer feiler selv om filområdet har plass
E-postkvotepostkasse eller samlet kontomeldinger avvises eller kan ikke lagres
Backupkvoteantall kopier eller backupvolumnye kopier tas ikke eller gamle slettes
Prosess-/I/O-grensesamtidighet eller diskaktivitetsiden blir treg eller svarer med ressursfeil

Mer lagring løser bare den første raden. En oppgradering som gir flere GB, men samme inode- eller prosessgrense, kan etterlate problemet uendret.

Hvorfor små filer kan bruke mer enn forventet

Filsystemet lagrer data i blokker. En fil med noen få bytes kan bruke en større tildelingsenhet på disken, i tillegg til metadata. Derfor kan summen av filenes synlige størrelser avvike fra faktisk brukt filsystemplass.

GNU Coreutils forklarer forskjellen mellom apparent size og faktisk filsystembruk i dokumentasjonen for du . Forskjellen blir særlig synlig ved mange små filer, sparse filer, metadata og åpne filer som er fjernet fra katalogen men fortsatt holdes av en prosess.

Kontrollpanelet, df og du kan dermed vise ulike tall uten at ett av dem nødvendigvis er «feil». De måler forskjellige nivåer.

Symptomer på full disk eller inodekvote

Mulige symptomer er:

  • nye bilder eller dokumenter kan ikke lastes opp
  • CMS-oppdatering stopper midtveis
  • cache, økt eller midlertidig fil kan ikke opprettes
  • logger slutter å skrives
  • backup feiler eller blir ufullstendig
  • e-post kan ikke lagres hvis den deler kvote
  • database eller applikasjon gir generell skrivefeil
  • deploy kan ikke pakke ut nye filer
  • kontrollpanelet viser 100 prosent filbruk selv med ledige GB

Samme symptom kan ha andre årsaker, som rettigheter, read-only-filsystem eller applikasjonsfeil. Bevar hele feilmeldingen og tidspunktet før noe ryddes.

Vanlige kilder til ukontrollert vekst

KildeTypisk mønsterRiktig eier
Bildevariantermange størrelser per opplastet bildeCMS-/temaansvarlig
Cachesvært mange små filer med tidsbegrenset verdiapplikasjon eller cacheverktøy
Økter og midlertidige filerkontinuerlig vekst og mange gamle posterapplikasjonsutvikler
Loggernoen få store filer eller mange arkiverdriftsansvarlig
Backupstore arkivfiler eller utpakkede kopierbackupansvarlig
Staging og gamle versjonerhele nettstedet kopiert flere gangerleverandør/utvikler
E-post i Maildirén eller flere filer per meldinge-postadministrator
Avhengighetertusenvis av små programfilerutvikler og deployløp
Genererte rapporter/eksportermange like filer med dato i navnetsystemeier
Kompromitteringukjente skript, spamfiler eller rask, uforklarlig vekstsikkerhetsansvarlig

Et «cache»-navn er ikke garanti for at hele mappen trygt kan tømmes. Produktet kan blande midlertidige og varige data eller kreve sin egen ryddefunksjon.

Mål på riktig nivå

I kontrollpanelet

Start med leverandørens oversikt. Noter:

  • total og brukt diskkvote
  • total og brukt inode-/filkvote
  • separate tall for nettside, database, e-post og backup
  • tidspunkt for siste oppdatering
  • om papirkurv, skjulte filer og snapshots telles

Et panel kan oppdatere forbruk periodisk. Ikke anta at en sletting har mislyktes bare fordi tallet ikke faller samme sekund.

Med read-only-kommandoer

Hvis dere har SSH og vet hvilken webrot som er riktig, kan disse GNU/Linux-kommandoene lese status uten å slette noe:

df -h .
df -i .
du -x -h --max-depth=2 . | sort -h
du -x --inodes --max-depth=2 . | sort -n

df -h viser blokk-/diskbruk for filsystemet, mens df -i viser inodebruk. GNU-dokumentasjonen for df beskriver feltene.

du-variantene fordeler bruk i katalogtreet. -x holder søket på samme filsystem. Alternativene er ikke identiske på alle operativsystemer, og en delt hostingkonto kan begrense dem. Bruk leverandørens verktøy eller be support hente en rapport hvis dere er usikre.

Kjør ikke et stort fullsøk på produksjon under toppbelastning uten å vite kostnaden. Selv read-only skanning av millioner av filer kan gi betydelig I/O.

Finn vekstkilden før dere rydder

Bruk denne rekkefølgen:

1. Bekreft hvilken grense som er nådd

Er disk full, er inodekvoten full, eller feiler bare én applikasjon? Ta skjermbilde eller eksporter målingen med tidspunkt.

2. Finn den øverste katalogen som skiller seg ut

Sammenlign både bytes og filantall. En backupmappe kan dominere bytes. En cache- eller øktmappe kan dominere antall filer.

3. Finn prosessen som oppretter innholdet

Se på filnavn, endringstid, applikasjonslogg og planlagte jobber. Ikke konkluder bare fra mappenavnet.

4. Avklar forventet oppbevaring

Hvor lenge skal logger, eksportfiler, økter og backup beholdes? Finn avtalen, systeminnstillingen eller en navngitt eier.

5. Stopp ukontrollert produksjon

Hvis en feil jobb lager tusenvis av filer, må jobben pauses eller rettes før opprydding. Ellers fylles kvoten på nytt mens dere sletter.

6. Bruk systemets ryddefunksjon

Bruk CMS-, cache-, backup- eller loggsystemets dokumenterte opprydding når den finnes. Da kan indeks, metadata og avhengigheter oppdateres sammen med filene.

7. Mål på nytt og verifiser nettstedet

Kontroller disk, inodes, nettsted, innlogging, opplasting, e-post og neste planlagte jobb. Dokumenter hvor mye som ble frigjort og om veksten fortsatte.

Sikker opprydding etter type

Cache

Avklar om cache kan regenereres, om tømning gir en kort belastningstopp, og om det finnes en innebygd purge. Etter tømming må dere følge feilrate og origin-/serverbelastning mens cachen varmes opp igjen.

Backup

En backup på samme konto kan være nyttig for rask restore, men er ikke tilstrekkelig beskyttelse mot kontotap, kompromittering eller diskfeil. Bevar godkjente kopier på et separat system før gamle lokale kopier fjernes.

Kontroller at arkivet kan åpnes og at restoreprosessen er dokumentert. En liste med filnavn er ikke en gjenopprettingstest. Se backup- og restoreguiden for nettsteder før rotasjon endres.

Logger

Ikke slett logger som trengs til aktiv feilsøking, sikkerhetshendelse eller dokumentert oppbevaringskrav. Innfør rotasjon, komprimering, maksimal alder og ekstern logglagring der behovet tilsier det.

En loggfil som er slettet mens prosessen fortsatt holder den åpen, kan fortsette å bruke plass uten å vises i katalogtreet. Dette er en av grunnene til at df og du kan være uenige. Driftsansvarlig må da håndtere prosessen kontrollert.

Bilder og mediefiler

Finn originale filer og genererte varianter. Et CMS kan lage en variant per definert bildestørrelse. Fjern ikke tilfeldige varianter hvis databasen eller HTML fortsatt peker til dem. Reduser unødvendige størrelser i konfigurasjonen og regenerer gjennom et støttet verktøy.

Staging, deploy og gamle versjoner

Bekreft hvilken versjon som er aktiv, hvilke symlinker eller releasepekere som brukes, og hvordan rollback fungerer. En gammel mappe kan være eneste testede returpunkt. Sett en eksplisitt regel for hvor mange releases som beholdes etter vellykket deploy.

E-post

Hvis e-post deler hostingkonto eller filkvote, må opprydding skje gjennom postkassen eller leverandørens administrasjon. Ikke slett Maildir-filer direkte uten en dokumentert prosedyre; indekser, mapper og samtidige klienter kan bli inkonsistente.

Når rask vekst kan være en sikkerhetshendelse

Behandle plutselig, ukjent vekst som mer enn et lagringsproblem hvis dere ser:

  • ukjente PHP- eller skriptfiler
  • filer med tilfeldige navn i opplastingsmapper
  • spam- eller phishinginnhold
  • nye administratorer eller planlagte jobber
  • uventede arkiver, redirects eller DNS-endringer
  • høy utgående e-post eller trafikk samtidig

Isoler berørt funksjon, bevar bevis og undersøk tilgang, sårbarheter og logger. Ikke «rydde bort» alle spor før rotårsaken er forstått. En ren backup fra før kompromitteringen og en dokumentert gjenoppbygging kan være tryggere enn punktvis sletting.

Beregn tid til neste grense

En enkelt måling viser status. Minst to målinger viser retning.

(ledig kvote) ÷ (netto vekst per dag) = omtrent dager til full

Eksempel:

MålingDag 1Dag 31Vekst
Disk8,0 GB9,5 GB50 MB/dag
Filer180 000270 0003 000/dag

Med 300 000 som filgrense er det bare omtrent ti dager igjen, selv om disken kan ha god margin. Varsle på både prosent og veksthastighet. Et fast 80-prosentvarsel kommer for sent hvis en feil jobb kan lage 20 prosent på én time.

Spørsmål før dere kjøper mer lagring

  • Hva er diskgrensen og inode-/filgrensen i hver plan?
  • Er grensene harde, myke eller bare varslede?
  • Teller mapper, e-post, skjulte filer, cache, logs, staging og backup?
  • Får en oppgradering både mer disk og flere inodes?
  • Kan leverandøren vise bruk per katalog eller tjeneste?
  • Hvor ofte oppdateres forbrukstallene?
  • Hva skjer ved full kvote: varsel, skrivefeil, stans eller ekstrakostnad?
  • Kan backup eksporteres uten å bruke ekstra plass på samme konto?
  • Finnes automatisert rotasjon for logger, cache og backup?
  • Hvilken hjelp inngår ved diagnose og gjenoppretting?

Be om svar i dokumentasjon eller avtale. «Mye lagring» sier ingenting om filgrensen.

Forebygging

  1. Mål disk og filantall minst ukentlig for kritiske nettsteder.
  2. Sett varsel før både myk og hard grense.
  3. Gi cache, logger, økter, eksport og backup en eksplisitt oppbevaringstid.
  4. Hold backup utenfor produksjonskontoens eneste feilområde.
  5. Fjern ubrukte stagingkopier og gamle deploys etter godkjent rutine.
  6. Test opplasting, backup og restore etter større endringer.
  7. Undersøk rask, uforklarlig vekst som mulig feil eller kompromittering.
  8. Dokumenter hvem som eier hver katalog og automatiske jobb.

Bruk vedlikeholdsplanen for nettsider for å gjøre kontrollene repeterbare.

Lagring hos Vymo

Vymos standardtilbud er én enkel side som Vymo setter opp og hoster. Kunden får foreløpig ikke filsystem-, SSH- eller kontrollpaneltilgang, og den publiserte standardleveransen oppgir ikke en kundestyrt inodekvote.

Tilbudet er ikke laget som filarkiv, videoplattform, kundestyrt WordPress-webhotell eller lagring for store nedlastinger. Har virksomheten mange bilder, dokumenter eller krav til eksport og lagringskapasitet, send filtyper, antall og forventet vekst før bestilling .

For en enkel presentasjon av virksomheten kan dere se hva den gratis nettsiden inkluderer .

Trenger bedriften en enkel nettside?

Vi lager én enkel nettside for bedriften og inkluderer hosting de første 12 månedene.