This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Data Disk is filling up - please check. Current usage: 83%

A client of ours have two ASG220s in a HA cluster active active. Just recently they have been getting email notifications saying the following ...

-- 
HA Status          : CLUSTER SLAVE (node id: 2)
System Uptime      : 10 days 20 hours 57 minutes
System Load        : 0.11
System Version     : Astaro Security Gateway 7.202

Please refer to the manual for detailed instructions.

Logged onto the ASG and the dashboard shows
CPU 13%
RAM 84%
SWAP 15%
Log disk 1%
Data Disk 3%

Logged onto the ASG at the command line via ssh
Master Node1 /var/storage 3% used
Slave Node2 /var/storage 86% used

There is 22GB in /var/storage/chroot-http/tmp.

In the short term can I delete these files?

The official reply from ASG support is to perform a "Factory Reset" on the slave. This is the second time this happened now.

We have other clients that also have HA cluster active active - ASG220 / ASG320s etc with no such issues.

Anyone else out there had any similar problems?


This thread was automatically locked due to age.
  • Right.  That was why I suggested a reboot.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • that wouldn't have helped... we rebooted a couple of times between then and now. It just kept adding and adding text to the file because the cronjob kept running - even after the reboot it just added a line every minute...
  • Thanks for confirming that.

    I bet the Astaro support guy is embarrassed!

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Commenting out the cronjob is not a permanent solution. The crontab is dynamically created, and a change of the configuration might lead to a re-write of the crontab. 

    When the crontab is dynamically re-created, all files named /etc/crontab.whatever are considered static, permanent jobs and merged together in the final /etc/crontab file, so I'd suggest you check if there is a crontab.something file existing that contains the command you want to remove, and remove that file, too.

    Cheers,
     andreas
  • Doesn't seem as if there's anything left. Just checked the files.
    Will let you know if anything happens though.