Full Snapshots missing loads of files

Installation Home Assistant OS
11

I’ve added the config-folder to my nightly backup on the Synology, too. Until now I used Active Backup just to get the snapshot-files to a second location.

But I see this only as a workaround. A backup should be working bullet-proof.

I googled the term from the error log at github and found, that there is a error alreay reported at 18.10.2018 in issue #17583, later merged to issue #779 and still open.

12

Agreed. It seems to be a rather basic stuff and… nothing.
Weird.

GV

13

Well, I use googledrivebackup ( an add-on for home assistant complete/ home assistant supervised) and my backups are reliable. Restore is something different :frowning: Friday I tried to restore on a new installation, at the first attempt only the add-ons were restored, nothing of the configuration. Only after I restored the same backup again everything was there.

14

I solved this problem by moving the database files to the “shared” folder.
This way the missing database file doesn’t corrupt the backup of the config folder.
There is a long thread on GitHub for this issue.

15

Can you briefly confirm how you moved the database to a different folder? Would the formatting be as below:

recorder:
  purge_keep_days: 5
  db_url: sqlite:////home/user/.homeassistant/share/database

Where “database” is a folder I created in the share folder, visible when browsing via samba. Did you move the db file before or after restarting HASSIO?

I’ve just checked several of my automated Google Drive snapshots and have been horrified to find that half of the configuration has not been backed up.

16

This is the path I used:

sqlite:////share/hassio_db/home-assistant_v2.db

To retain the data, I connected via ssh, stopped home assistant, copied the files, started home assistant again. After verification I deleted the old files.
If you don’t need to retain the data, you can just change the path and do a restart. The file will be created, if it doesn’t exist.
I was shocked as you to find all of my backups useless, and astonished, that obviously this is not regarded as top priority issue.

2 Likes
17

Thanks, I did exactly that just now and it seems to be working perfectly in its new location.

For anyone wondering:

  1. Add the following to your config under recorder: db_url: sqlite:////share/hassio_db/home-assistant_v2.db
  2. Create a folder “hassio_db” in the share folder of your hassio install
  3. Connect via SSH, enter command ha core stop
  4. Copy the database file to the new location hassio_db
  5. Enter SSH command ha core start and you’re back in action. Old database file can be deleted then

Hope this issue is resolved as a priority on github

1 Like
18

I can just redirect it without moving if I do not care about the data?

19

Yes you can.

20

I noticed the same and the solution provided here as listed by @jdbrookes worked for me.

I agree that this should be a high priority issue. Maybe if we all comment on the Github issue, it might get attention of the devs.

21

This is still happening. I’m fairly new to HA and I screwed up my automations.yaml that caused my HA instance to not start up… Long story short, I have the google drive auto-backup add-on and all of those backups were incomplete. Luckily I had one I’d done manually (albeit days earlier) that I was able to recover most of my work.

@seanomat, @jdbrookes, @Arjen_W have you guys had any issues since you moved the db to shared? Also, is recorder the only integration responsible for writing to the db? On its info page, it says:

The recorder integration is responsible for storing details in a database, which then are handled by the history integration.

Does this mean we also need to let history know about the db file’s new location? It doesn’t seem to me that this is necessary, but since I’ve really only been playing around with Home Assistant for a month, I’m scare to just move the db, plus I’ve been collecting utility_meter data and would hate to lose that history.

22

I don’t have any issues after moving the DB location. Also upgrading to version0.112 went fluidly.
I only changed the settings as described above, no other setting changes were needed.
I must say that I hardly use the history tab at all, so I have no idea if that is working as it should be, but I do believe that it works as expected

23

Yes the backups are now working correctly, I’ve inspected a few and found all of the yaml intact. The database file also seems to be intact in it’s own folder but I don’t know for sure that this is backed up correctly as I haven’t needed to restore a snapshot.

24

Yes, moving the database is a working workaround.
All other integrations use recorder so no need to change the database location anywhere else.

25

@Arjen_W, I agree with your suggestion to comment on the Github issue as a way to get the attention of the devs, but I’m having trouble finding the issue! Could you possibly post a link please?
TIA.

26

Did this get fixed in the new release of the supervisor?

27

I don’t know. As my config still contains the workaround, I haven’t tried to check it again without the workaround in place.
@AndrewJ: sorry for not reacting earlier, was kinda busy. There were some issues logged, but I think those were all closed by a remark that it was due to Supervisor. I thing the issue that @CaliKev linked is the most important one, but the issue might already been solved.

28

Hello everyone! Is anyone else having problems with snapshots? All of mine, both complete and partial, are corrupted. Does anyone have any solution!. Thank you. snapshot|690x487

29

did you find any solution for this. I am having this problem not just in automation but also in normal UI

30

No, as a workaround I backup the config folder complete not just the snapshot.

As I use a Synology NAS it was just another backup task.