/backup nearly full? How to resize?

Configuration
1

For a very long time my /backup folder, as shown in Glances, is red presumably as it is close to being full. I have no idea what the size limit is and I have limited the number of backups kept on the HA VM to 3 as I have a daily in Google Drive anyway.

image
image861×597 38.2 KB

image
image1572×577 28.7 KB

I recently expanded the drive space for the VM to 245GB but that did not do anything for the backup folder. I recently followed some CLI commands to resize a folder on another VM but I don’t want to venture in doing so on my HA install in case I blow it up.

Is there some way to address this other than reducing the backups to just 1 or maybe 2? What is the limit?

2

The limit is your space. You can use google drive backup to automate backups and how many to keep locally vs. in your free google drive as well as you can vastly reduce the size of the DB by adjusting the recorder in configuration.yaml

3

@KruseLuds - My HA DB file is just over 5GB and I have taken steps to try to reduce the data stored in it mostly by tweaking the code in my 50+ ESPHome devices as some were generating excessive data. Of course, there are other chatty devices that I can tone done like all the energy reporting devices however all of this is addressing my issue from another perspective - that of using/needing less space, instead of expanding the space available.

I already use Google Backup and have 15 daily backups (202GB total) uploaded nightly.

What I believe is hogging a lot of space is likely Influx DB but I have not found the DB file or a good way to see its size. I have cut down the retention period for the DB but I am not too sure it helped much likely because it cut off older data when I was storing less data so it didn’t make a huge difference.

Anyway, back to my original question… why is glances showing the folder in red? I assume it is to tell me that I am close to it’s quota… if so, how do I expand the quota? I am guessing the quota was some percentage of the drive space from when I first setup the VM. I have increased the disk space available to the HA VM several times but that folder has always remained red. I currently have 91GB available so if all of that were available for the backup folder, why is it red?

Given what you said, I tried df - h in terminal but can’t make much sense of it as most of the folders report the same values for used and available which I believe is just the system total (81GB, not sure why not 91GB).

image
image823×754 61.8 KB

Also, another weird thing is that if I access my HA VM using samba (Files explorer), I find myself in a loop once I click the homeassistant folder within config. It just keeps opening what appears to be a nested homeassistant folder that is identical to the base homeassistant folder.

image
image1333×61 2.17 KB

I don’t know much about Linux but I am guessing it is a symlink pointing back to itself?

When I check the size, I get 108GB:
image

I can’t get into the homeassistant folder though, so I have no idea why it is so large (other than possibly Influx DB).

Edit: My other HA VM (test system) doesn’t even have the homeassistant folder… I wonder whether this folder is something retained from some old version. Maybe I should reinstall and restore (or selectively restore) to hopefully get rid of it.

4

Did you start doing this sort of tweaking in your configuration.yaml? You can exclude specific sensors and reduce the commits to maximize performance, etc.

#
# Changes to the default logging parameters:
#
recorder:
# remove this auto_purge line when 2024.8.X comes out as it resolves a bug
#  auto_purge: false

#
# We leave auto-purge on (which is the default if the
# setting is not specified) - which weirdly takes place
# every daty at 04:12 local time - since we don't care 
# how often it is purged but rather how much data is
# kept -  
# auto_purge: false
# purge_keep_days default is 10 if setting is missing
  purge_keep_days: 30
#
# If not specified, the commit_interval is defaulted to 1
# (1 second) - I have decided to cut in half the number of
# commits made to the database by just changing this to 2
# (hopefuly this will help prolong the life of the ssd)
  commit_interval: 2
#
# These command_line entities are called pretty often and 
# are just using up too much log spece - which disrupts from
# my being able to easily anallyze the logs on the fly - and 
# not worth the effort to save for any reason (unless I want
# to debug later in which case can easily be done by just 
# commenting out one or more of the below lines):
  exclude:
    entities:
#      - SENSOR.HASSIO_DNS_ERROR_COUNT_IN_LAST_10_MINUTES
# Add the other hidden input_text sensors
      - sensor.weewx_last_array_data_formatted
      - sensor.WEEWX_LAST_SENT_TO_AWEKAS
      - sensor.WEEWX_LAST_SENT_TO_WUNDERGROUND_PWS
      - sensor.WEEWX_LAST_SENT_TO_OWM
      - sensor.WEEWX_LAST_SENT_TO_METEOSERVICES
      - sensor.WEEWX_LAST_SENT_TO_PWSWEATHER
      - sensor.WEEWX_LAST_SENT_TO_WINDY
      - sensor.WEEWX_LAST_SENT_TO_WINDGURU
      - sensor.WEEWX_LAST_SENT_TO_WOW
      - sensor.WEEWX_LAST_SENT_TO_CWOP
      - sensor.WEEWX_LAST_SENT_TO_WEATHER365
      - sensor.WEEWX_LAST_SENT_TO_WEATHERCLOUD
#      - sensor.WEEWX_LAST_REST_CALL_FAILURE
      - sensor.SYSLOG1_ERRORS
      - sensor.CONSOLE_LAST_SENT_TO_WEATHERUNDERGROUND
      - sensor.CONSOLE_LAST_SENT_TO_WEATHERCLOUD
      - sensor.CONSOLE_LAST_SENT_TO_AMBIENTWEATHER
# ...and the uptime sensor counters shouldn't be logged....
      - sensor.rpi_uptime
# ...and we don't need to care about past ink levels...
      - sensor.epson_wf_3730_series_black_ink
      - sensor.epson_wf_3730_series_cyan_ink
      - sensor.epson_wf_3730_series_magenta_ink
      - sensor.epson_wf_3730_series_yellow_ink
5

Not to your extent but yes. However, I want granular data for a longer period of time so while I can certainly reduce storage of granular data for a majority of the entities, for now I am happy with giving the system more space… except it doesn’t seem to be enough if that folder in red is to be considered in peril.