Bekijk Volledige Versie : Probleem tijdens dagelijkse backup
Ik heb in Directadmin ingesteld dat er elke nacht automatisch een backup wordt gemaakt naar een externe lokatie. Dit ging altijd goed alleen sinds een aantal dagen krijg ik voor 2 users waar een backup van gemaakt moet worden onderstaande foutmelding. Nu vroeg ik mij af in welke hoek ik dit moet zoeken. Is er geen vrije ruimte meer op de harddisk van de server? Of is dit in de tmp directory? En zo ja, hoe vergroot ik deze?
User admin has been backed up. <3:01:10>
Error Compressing the backup file user.admin.sitename.tar.gz :
gzip: stdout: No space left on device
/bin/tar: /home/tmp/admin/sitename/user.admin.sitename.tar.gz: Cannot write: Broken pipe
/bin/tar: Error is not recoverable: exiting now
Kevin Bentlage
08/11/15, 22:20
De error melding geeft inderdaad aan dat er op dat moment te weinig schijfruimte beschikbaar was voor het maken van een backup.
Heb je SSH toegang? Zo ja, dan kun je met het commando "df -h" het actuele schijfverbruik opvragen, misschien handig dat je die output hier post.
Sent from my iPhone using webhostingtalk mobile app
Onderstaand de output. Ik zou hieruit zeggen dat ik nog genoeg ruimte zou moeten hebben?
http://s21.postimg.org/7nzh01fqv/Knipsel2.png
Hoeveel diskspace gebruiken die users?
CharlieRoot
09/11/15, 08:21
Probeer ook df -i (je doet nu vermoedelijk df -h)
Je hebt nu nog 13GB vrij, maar ik vermoed dat hij tijdens het maken van de backup die 13GB volpompt en dan tegen een limiet aanloopt. Je ziet namelijk dat het backuppen van de admin user wel lukt, maar vervolgens is je ruimte op en kan hij de tar.gz niet kwijt.
13GB zal de site wel niet zijn.
Controleer even met ulimit -f wat de max. filesize is voor de gebruiker die de backups maakt. Denk dat deze nu op max 1GB staat.
Bedankt alvast voor de antwoorden. Hierbij de antwoorden op jullie vragen.
1) Uitkomst df -i
[root@srv1 ~]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/VolGroup00-LogVol00
16204320 662932 15541388 5% /
/dev/sda1 26104 59 26045 1% /boot
tmpfs 218213 1 218212 1% /dev/shm
2) De users waarvan de backup fout gaat gebruiken volgens directadmin 4652mb en 15113mb.
-> Lijkt me dus duidelijk dat het bij de 2e user fout gaat door de gebruikte diskspace. Maar is dit ook de reden van de user die 4,6gb gebruikt?
systemdeveloper
10/11/15, 02:27
Dat kan best. Je hebt de ruimte van de backup die da tijdelijk maakt in je /home/admin/admin_backups/ plus de ruimte die hij gebruikt voor het aanmaken van de tar.gz wat het uiteindelijke backupbestand wordt. Afhankelijk van de compressie mogelijkheden kan het best zijn dat je nét tegen je limiet aanloopt.
En waarschijnlijk lopen er ook wat taken parallel. Dus tijdens het zippen van de 1e gebruiker wordt ook al de backup van de 2e gebruiker gemaakt, en hopla alles zit vol nog voordat de zip van de eerste afgerond is.
MosterdNaDeMaaltijdTip: Met een goede monitoring had je dit kunnen zien aankomen.
Met directstadmin Back-up heb je 3x de ruimte nodig.
1x origineel
1x temp map
1x zip
Pas als de zip succesvol is word de temp mag geleegd.
100mb userdata heeft dus tijdens de Back-up 200mb extra ruimte nodig.
Denk dat je dus tegen ruimte problemen aanloopt.
Sent from my iPad using webhostingtalk mobile app