XG -Report partition full

Hi,

you need to review the log retention settings to assist with your full disk recovery issue.

Ian

The minimum log retention is one month.

As told in my post, the default 80GB report partition of the VM is filling very quickly, in about 20-25 days.

So log retention is not a good option and the customer needs more for compliance.

You could increase the Disk space with a new appliance and the tools your hypervisor gives you. Then spin up the VM and restore a backup of your current appliance. This will result in a new appliance with a larger space. 

Hello Alex,

of course you can do the same in VMware, why not?

The step resize2fs /dev/var is inside the guest, so this does not depend on the type of hypervisor.

Hello,

Your answer is technically OK. But the support told us not to do that:

"the XG along with the UTM do not learn about increased disk capacity, because it would require dynamic space allocation which could lead to a security breach due to stuff in the expanded disk."

I don't have so much time to really go deep on this to evaluate how dynamic space allocation is different on an azure storage than on a classic VM.

I think that the Lucar Toni answer is the good one an as i'm in cluster, i'll recreate the VM one by one with the good size.

By the way, this is another issue that shows the poor development quality of XG for a production environment: logrotate not working and firewall/email down for a low space issue and bad partitioning conception.

We are a lot on this forum that really don't understand how did Sophos goes that wrong on XG as Astaro/UTM is a really nice product.

Hurry up Sophos, XG is V19 now, it's time to have a good product.

You should differ between 3 components. Debugging (live), Logging and Reporting. 

Those three components are in the products. UTM did this with a log retention principle of doing this within .log.gz files and archiving this. But it still was plain .log files. 

I would not be interested in old data anymore in a .log. 

You want to secure your company. You want to have data which is meaningful to represent the current ongoings within your network. A .log File is not useful for this approach. 

So the movement towards IT Security is to use SIEM like solutions to get a know about the behavior. And this is included within the Data Lake of Central. And Threat Analyst can read this data perfectly fine. This kind of data is not stored in .logs as you cannot dig deep enough and use tools in a quick manner. 

Debugging for a broken module can be done within a .log. Most likely you do not need to go back the past 30 Dayish or so. As the firewall does not store that much data in .log anymore, it will not rotate that much. 

The default 80 GB for a VM are likely to small for you. But afterwards you should not run into this issue that much. And you should think about getting your Reporting into the datalake instead. This saves the space locally. 

Going forward and looking at Threat Analysis, this is something you should look into.