[IDEA] XBian-backup

[Nachteule]

@Skywatch
Maybe your IMGKEEP variable is set to 0, can you show me your content of file /etc/default/xbian-snap?

[Skywatch]

Terminal

# enable periodic running (daily / weekly / monthly)
ENABLEDSCHEDULE=yes
KEEPDAYS=3
KEEPWEEKS=2
KEEPMONTHS=0

# enable creating of snapshot before APT operations. if wrong packages installed or something stopped working,
# restoration will take few seconds to state before APT run
ENABLEDAPT=yes
KEEPAPT=3

# exclude those subvolumes by default for btrfs-auto-snapshot operations (comma separated list)
EXCLUDESUB=

# auto clone / image creation should be run: none/daily/weekly/monthly
IMGPLAN=daily

# backup to img file (file) (in case of total SD card corruption, your system can be restored by reflashing this image)
# or directly to block device (block)
IMGTYPE=file

# path to img including file name (/media/my_disk/xbian_backup.img) or block device (/dev/sda1)
IMGDEST="/mnt/540/kitchen/$(hostname)-$(date +%F).img"

# how many images should be kept (0 means imlimited)
IMGKEEP=7

# auto backup of /home should be run: none/daily/weekly/monthly
HOMEPLAN=weekly

# path to img.gz including file name (/media/my_disk/xbian_home_backup.img.gz)
HOMEDEST="/mnt/540/kitchen/$(hostname)-$(date +%F).img.gz

# how many /home images should be kept (0 means imlimited)
HOMEKEEP=3

[Nachteule]

Hmmm, looks fine for me.

So, output in /var/log/syslog would help, or for a test you could run the clean command manually:

Terminal

sudo xbian-config xbiancopy '/mnt/540/kitchen/$(hostname)-$(date +%F).img' 7

(please note: those '' are important)

or better this one:

Terminal

sudo xbian-config xbiancopy doclean "$(xbian-config xbiancopy imgdest)" 7

(please note: those "" are important)

[Skywatch]

No /var/log/syslog it seems.....

Terminal

xbian@kitchen /var/log $ ls
alternatives.log dpkg.log.1 lastlog
alternatives.log.1 dpkg.log.2.gz lircd
alternatives.log.2.gz dpkg.log.3.gz mountall-orig.log
alternatives.log.3.gz dpkg.log.4.gz ntpstats
alternatives.log.4.gz fail2ban.log pycentral.log
apt fail2ban.log.1 samba
bootstrap.log fail2ban.log.2.gz unattended-upgrades
btmp fail2ban.log.3.gz upstart
btmp.1 fail2ban.log.4.gz watchdog
clamav fail2ban.log.5.gz wtmp
ConsoleKit faillog wtmp.1
dmesg fontconfig.log
dpkg.log fsck
xbian@kitchen /var/log $

I'll try the second command later if I can.

[Skywatch]

Is a reboot needed to set changes in /etc/default/xbian-snap ???

The 'clean' command didn't do the trick either.

Now I see that since I changed images to keep from '0' to '7', no backups havebeen made to the server by either pi1 devices. Pi2 devices all work as expected.

I have changed it back to '0' images to keep and will manually remove older ones weekly as I have been doing.

[Nachteule]

(15th Jun, 2016 07:23 PM)Skywatch Wrote:  Is a reboot needed to set changes in /etc/default/xbian-snap ???

No

Quote:The 'clean' command didn't do the trick either.

Without getting messages from syslog we never can figure out what's going on

Quote:Now I see that since I changed images to keep from '0' to '7', no backups havebeen made to the server by either pi1 devices. Pi2 devices all work as expected.

I have changed it back to '0' images to keep and will manually remove older ones weekly as I have been doing.

Making images and clean images are two completely different tasks. So I would suppose we're searching the culprit at wrong place. Probably one faulty cron job from yesterday is still running and blocks all new jobs from today (had this on one device a few weeks ago)

Currently having 4 different devices in test (2xRPi1, 1xRPi3, 1xHummingboard), all of them works as expected

[Nachteule]

Checked it additional 2 days, everything works as expected

Only found one limitation (github issue)

Will add this feature before I'm continuing working at BT configuration

[Skywatch]

@Nightowl

Did some more testing on this.

With one pi1, reverting from imgkeep=7 to imgkeep=0 got it working again, no idea why though. Maybe have some more time next week to look into it more.

On the other pi1, still no backups since 12/06/16. I even tried from within xbian-config and for some odd reason it quickly flashes up a message (to short to read it all) and then appears to finish, very quickly. This pi will no longer back up either using manual or anacron method. This one needs more time too, and I hope to find something that will help soon.

That's as far as I have had time to get. Grrrr....

[Nachteule]

Yeah, would be very interesting to know what's going on there

• First you could check by command sudo btrfs-auto-snapshot list if daily snapshots are still generated (means that (ana)cron is running and not blocked)
• Second, you could check if there are files like xbiancopy.* in /tmp folder
• Third, check if stettings in /etc/default/xbian-snap are still ok
  

[Skywatch]

Thanks I'll take a look and see what I find

Of course I'll report back and let you know

[Skywatch]

One thought I did have is that both of these have had LCDproc installed to get display working with xbian, maybe that's the culprit, but I have no clue as to how or why!

[Nachteule]

I'm convinced you'll find the culprit

[Nachteule]

@Skywatch

Code:

IMGDEST="/mnt/540/kitchen/$(hostname)-$(date +%F).img"

This mounted network drive, is this NFS or SAMBA share? I have strange issues on RPi1 using SAMBA share (one week ok, then lot of OOM killer, system freezes and so on). RPi2/3 is ok with SAMBA shares

[Skywatch]

My drives are SMB mounts.

I checked today and what I find is amazing!

All pi have started working again by themselves. All are backing up to the smb share once a day (although still during working hours, grrr).

*BUT*....

On all 4 pi the /etc/default/xbian-snap files are truncated now with nothing below the line EXLUCDESUB= in that file.....*and* the EXCLUDESUB= is now at the bottom of the file too!!!

I am sure that I have done none of this as I have had no time to play with these machines this week, so unless I am doing this in my sleep it is totally baffling!

I have put the files how they were and am rebooting; lets see what treats that leads to!

------UPDATE-----

Well this is interesting. I decided to try out 17A2 and so enabled devl. One upgrade was showing but would not download due to an 'error' in /etc/default/xbian-snap. I simply commented out all the 'home' backup lines as well as the Excludesub line and hey presto it worked and upgraded! So something is going on that is beyond my level of knowledge (not hard to do)

[Skywatch]

Had the exact same problem today with all pi here (1&2). They would not install the upgrades from xbian-config until I rem'd out all 'home' and 'excludesub' lines from within /default/xbian-snap.

There is something unexpected going on here for sure.