I was having an issue trying to delete old snapshots using shell_command. After a year of being annoyed about it, I finally got it working today. Along the way I figured out a few important things I feel are worth sharing to the community. Fully functional script at the end.
shell_command runs in the homeassistant container if you are running HASSIO. I’m not sure about other installation types, but probably consistent. The mounted drives are different in this container vs. the host system that you can access via the developer SSH on port 22222. Keep that in mind when testing via SSH. You’ll want to run a shell inside the homeassistant container to test from or else the paths won’t be right if you’re on the host.
The backups are not mounted by default in the homeassistant container, so you have to mount them in your script. In my case, with full HASSIO, I mounted /dev/sda8 on /mnt/data and the snapshots are at /mnt/data/supervisor/backup. You can mount wherever you want. I chose /mnt/data to be consistent with where the host system mounts that device so that I don’t have to remember different locations based on what I’m logged into.
Although the backup folder wasn’t mounted for us in the homeassistant container, /config, /share and /ssl are available. The addons folder is not mounted either, but mounting the drive ourselves gives us that too, if you need it for some reason.
Note that all of those folders are technically subfolders on /dev/sda8, so when we mounted that drive to /mnt/data they are also accessible through that mount. For example, /config and /mnt/data/supervisor/homeassistant are the same folder on the disk. The other folders are also under the supervisor folder, but their names are consistent (share, ssl, backup, addons). I find it odd that the config folder is called homeassistant on the disk, but whatever.
A limitation I ran into with shell_command is that it doesn’t like to run multiple commands, nor does it handle for loops. I think it’s a limitation of the compact shell that runs the command (BusyBox). I worked around this limitation by making a bash script to do all the work and the shell_command just calls my script. I created my bash script in my config folder so that it’s part of my backups. Using a separate bash script file also lets me make changes without having to restart homeassistant, whereas editing the shell_command settings in configuration.yaml would require restarting homeassistant.
My bash script automates creating a temporary mount folder, mounting the drive, looping the available *.tar files over 7 days old and deciding which ones to keep or delete, then unmounting and removing the temporary mount folder. Aside from age, the decision to keep or delete requires examining the friendly name of the snapshot to determine if it’s one of the automated backups because I want to retain all manual backups regardless of age. I found a way to get the friendly name from the snapshot.json file inside the tar file without having to write it to the filesystem, so it’s nice and tidy.
My script file /config/tools/clean_snapshots.sh:
#!/bin/bash
echo "Cleaning up automated snapshots older than 7 days. Retaining manual backups of any age."
mkdir /mnt/data
mount /dev/sda8 /mnt/data
for i in `find /mnt/data/supervisor/backup/*.tar -mtime +7`
do
NAME=`tar xfO $i ./snapshot.json | jq .name`
AGE="$((($(date +%s) - $(date +%s -r $i))/86400))"
if [[ $NAME == *Automated* ]]; then
echo " - removing $(basename $i) from $AGE days ago ($NAME)"
rm $i
else
echo " + keeping $(basename $i) from $AGE days ago ($NAME)"
fi
done
umount /mnt/data
rmdir /mnt/data
It could be possible that I have to mount it with a different name.
Could you tell me how you figured out /dev/sda8 or do you see any other mistake I made?
It’s been a while since I tinkered with this, but I have it running on a NUC with Hass.IO as well. Maybe you can get more info from the logs if you set to debug level for shell command:
That looks like a path problem. It’s currently relative to the current directory, which probably isn’t what you expect when it runs in the automation. Try giving it a full path starting from the root of the filesystem (start with / and include your mounted drive path).
Hi Keith,
Just a word of caution on how Home Assistant runs shell commands. You use shell_command platform in your yaml, I have a bad experience with command_line one.
Depending on the way you invoke the Home Assistant, the shell commands can be executed with either bash or sh. The last one is severely limited, of course, and often leads to errors and problems.
I discovered this with my tiny CPUtemperature script that worked fine until I … implemented the systemd startup script. See the screenshot:
I documented this behavior in the original thread Autostart using systemd and I’m still trying to troubleshoot it further.
Similar phenomena could contribute to the problem described here.
thanks for the advice. Unfortunately I dont know how to get the full drive path. Could you make an example or tell me what to do / where to look to get the paths needed? In my previous post I also asked you how you managed to get the paths …
Thanks in advance!
Thanks for your efforts Keith. While the particulars on my Supervised installation differ, your posting here pointed me in the right direction to get the delete process working!
My Ubuntu 18 install has Home Assistant on /dev/nvme0n1p2 (the second partition on the box’s SSD), so with that mounted to /mnt/data, my backup directory can be found at /mnt/data/usr/share/hassio/backup.
@The-May, it’s been long enough that I don’t remember exactly. I used various commands to view what was mounted while I was logged into the developer SSH and poked at things until I found what I was looking for. I tried mounting each device to see what files it had on it. Try the findmnt command from SSH and see if that helps. I’m using a fully supervised install with the NUC image provided for installing Home Assistant, which seems to be the same disk devices as the RaspberryPi image I was using when I originally figured all this out. If you’re using a different setup your disk device & partition number may be different.
Thanks for the Information. I did not even know about developer SSH I will try and give feedback and eventually a detailed instruction for people that might be interested but do not know what to do if I succeed.
Cheers.
Did you ever solve that problem? I’m guessing that the shell script was not changed to be executable. The #!/bin/bash doesn’t make the file automatically executable. You have to manually change its mode. Check this article under the “Starting Off” section, Classic SysAdmin: Writing a Simple Bash Script - Linux Foundation . I think mode 700 should work. (By the way, I prefer the less sexist term “hashbang.”)
