Lagringsplass og inodes på webhotell
Ledig lagringsplass og ledige inodes er to forskjellige ressurser. Finn vekstkilden, eieren og en trygg slettefunksjon før dere kjøper mer eller fjerner filer.
Vymo · · 9 min lesing
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:
- brukt og ledig lagringsplass
- 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
| Grense | Måler | Vanlig symptom |
|---|---|---|
| Diskplass | allokert eller fakturert datamengde | opplasting, backup eller database kan ikke vokse |
| Inodes/filantall | filer, mapper og eventuelle andre objekter | nye små filer, økter eller cacheoppføringer feiler |
| Databasekvote | databasens størrelse eller antall databaser | lagring og spørringer feiler selv om filområdet har plass |
| E-postkvote | postkasse eller samlet konto | meldinger avvises eller kan ikke lagres |
| Backupkvote | antall kopier eller backupvolum | nye kopier tas ikke eller gamle slettes |
| Prosess-/I/O-grense | samtidighet eller diskaktivitet | siden 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
| Kilde | Typisk mønster | Riktig eier |
|---|---|---|
| Bildevarianter | mange størrelser per opplastet bilde | CMS-/temaansvarlig |
| Cache | svært mange små filer med tidsbegrenset verdi | applikasjon eller cacheverktøy |
| Økter og midlertidige filer | kontinuerlig vekst og mange gamle poster | applikasjonsutvikler |
| Logger | noen få store filer eller mange arkiver | driftsansvarlig |
| Backup | store arkivfiler eller utpakkede kopier | backupansvarlig |
| Staging og gamle versjoner | hele nettstedet kopiert flere ganger | leverandør/utvikler |
| E-post i Maildir | én eller flere filer per melding | e-postadministrator |
| Avhengigheter | tusenvis av små programfiler | utvikler og deployløp |
| Genererte rapporter/eksporter | mange like filer med dato i navnet | systemeier |
| Kompromittering | ukjente skript, spamfiler eller rask, uforklarlig vekst | sikkerhetsansvarlig |
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åling | Dag 1 | Dag 31 | Vekst |
|---|---|---|---|
| Disk | 8,0 GB | 9,5 GB | 50 MB/dag |
| Filer | 180 000 | 270 000 | 3 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
- Mål disk og filantall minst ukentlig for kritiske nettsteder.
- Sett varsel før både myk og hard grense.
- Gi cache, logger, økter, eksport og backup en eksplisitt oppbevaringstid.
- Hold backup utenfor produksjonskontoens eneste feilområde.
- Fjern ubrukte stagingkopier og gamle deploys etter godkjent rutine.
- Test opplasting, backup og restore etter større endringer.
- Undersøk rask, uforklarlig vekst som mulig feil eller kompromittering.
- 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.