Jeg har en reseller server, som kontant løber tør for plads. Årsagen er en række inkrementale backupfiler med følgende navnestruktur: Min resellerserver (bergholt.meebox.net) løber konstant tør for plads, fordi der gemmes en række inkrementale backuparkiver med følgende navnestruktur: myziparchive.zip.CBCWHJ.
De ligger i /public_html/***/wp-content/uploads/
Wordpressintallationen, der ligger i samme directory, har ingen backup-plugins installeret.
Er der nogen, der kan forklare, hvordan det kan ske? Og gerne også, hvordan jeg får det fikset, så serveren ikke crasher hele tiden?
Wordpressintallationen, der ligger i samme directory, har ingen backup-plugins installeret.
Er der nogen, der kan forklare, hvordan det kan ske? Og gerne også, hvordan jeg får det fikset, så serveren ikke crasher hele tiden?
Du kan evt. checke hvad der ligger i de backuparkiver og så se hvor/hvad der er i filerne, det må kunne give dig et indtryk af hvor filerne kommer fra. Burde dog ikke få din server til at crashe så du skal nok søge andetsteds for at finde grunden til det.
Problemet er, at jeg ikke kan downloade filerne, de er på 6GiB. cPanel crasher. Og FileZilla timer ud.
Serveren crasher, fordi backupsne maxer den ud på diskkapacitet.
Så er der jo ingen vej udenom end at få fat i meebox kundesupport, alternativt kan du prøve at skifte filrettighederne til det backupbibliotek den bruger og prøve at forhindre backup plugin i at skrive til biblioteket.
Jeg har fat i Meebox på en ticket, hvor jeg har bedt om at få filerne slettet.
Mappen står til 0755 nu. Hvad ville du ændre til? Men vil det ikke påvirke legitime skrivninger og læsninger.
Men der vil selvfølgelig være ræson i at lukke ned for skrivning til mappen, indtil problemet er fundet.
Du kan jo prøve med en chmod 0100 (er ikke mit speciale så du skal selv checke) på mappen, hvis det er din egen server kan du lave en chown root.root på mappen, så har kun root bruger adgang.
Tog et kig på error_log og fandt et script, der havde timet ud ad flere omgange (zipzip.php). Det lavede en backup af _alt_ i directoriet, inkl. tidligere backupper. Så kan det jo hurtigt løbe løbsk. Det mystiske er så, hvordan det script er havnet lige dér, og hvordan det er blevet kaldt dagligt igennem en længere periode.
Så nu krydser jeg fingre for det "bare" var det. Og så bekræftede det jo den gamle sandhed om, at det ofte er i logfilerne, man finder sandheden.
Og så bekræftede det jo den gamle sandhed om, at det ofte er i logfilerne, man finder sandheden.
Du kan ligeledes sammenligne fildato/tid med dine logfiler og se om du kan finde et tidspunkt der matcher, kan du ikke det har du sandsynligvis det problem at et sikkerhedshul på serveren gør at andre sites på serveren kan smide filer ind på din del af serveren.