[How to] Make periodic backups of whole OSMC system


#81

For remove this error notification I advice you to use next command option

mkdir -p backup

#82

Thanks, that got rid of the the mkdir error but still getting:

Going to back up to /media/Big\ Bertha/osmcbackup/2017-07-10 (unless I can't find it).
mount error: could not resolve address for SERVER: Unknown error
mount: can't find /media/Big Bertha/backup in /etc/fstab
looking for mounted media
media for /media/Big\ Bertha/osmcbackup not mounted in /media or /mnt or not formatted for linux

#83

It’s not quite that simple. You have to do something like

dd if=/dev/zero of=/media/Big\ Bertha/extimagefile bs=1M count=1 seek=50000
mkfs.ext4 -F /media/Big\ Bertha/extimagefile

That’s what I mean by ‘make an ext4 filesystem image’, before

mkdir /media/backup
mount -o loop /media/Big\ Bertha/extimagefile /media/backup

Run the above commands before you run osmc-backup and make sure you can ls /media/backup It’s better not to cd /media in fact. And yes, -p is a good suggestion. The above will make a 50GB ‘sparse’ image ie one which actually takes up only as much space as its contents need. This may have been the reason for the ‘painfully slow’ remark. You may do better with count=50000 and no seek parameter.


#84

It’s better don’t use mount a point name with spaces in it.


#85

Yes but once it’s loop mounted with a new name, should work.


#86

Cool, all seems to be working.

Should I add the lines to the script?

dd if=/dev/zero of=/media/Big\ Bertha/extimagefile bs=1M count=1 seek=50000
mkfs.ext4 -F /media/Big\ Bertha/extimagefile
mkdir /media/backup
mount -o loop /media/Big\ Bertha/extimagefile /media/backup

#87

No. The first two lines will wipe your last backup!
You could put the mkdir and mount lines in the script, and consider adding umount /media/backup and rmdir /media/backup at the end unless you want to leave it mounted to examine the contents.

Would be interested in how long it takes.


#88

Assuming it worked as expected it was pretty quick!

Error with rsync though?

system is on /dev/mmcblk0p2
Backing up system partition to /media/backup/2017-07-10/system
Backup directory is empty - making first copy
Time to back up system: 00h:05m:42s

boot is on /dev/mmcblk0p1
Backing up boot partition to /media/backup/2017-07-10/boot
Backup directory is empty - making first copy
Time to back up boot: 00h:00m:03s
cp: cannot stat '/home/osmc/osmc-backup/rsynclog2017-07-10': No such file or directory

2690832 KiB used in this backup
44945468 KiB available on drive
All done!

#89

No. Small bug - only happens on first backup. Thought I’d fixed it but no.


#90

Straight from the debian repo:

rsync version 3.1.1 protocol version 31


#91

Sorry I meant my script. It’s not an rsync problem, just me :unamused:

Thanks for testing! It should be that quick for only 2.7GB. That’s one of the advantages over imaging with dd :slight_smile:


#92

Script 0.1.6a, cloned this morning :slight_smile:

I’m going to exclude my downloads folder (because its usually full of rubbish) so that should keep it small.


#93

Try to add next string

touch $LOGFILE

after the string #73 in your script.


#94

Yeah. No I just didn’t redirect the rsync ouput in 229. It’s fixed in a version I have which uses a remote rsync server but forgot to add it to the master branch.


#96

Would it be worth having a ‘if then’ check for a mounted folder for an NTFS drive? So that if there isn’t a mounter folder then it creates and mounts, if there is then leave it alone and run as normally.

Could un-hash the check lines and then customise the paths. It makes it moron proof (aimed squarely at me!).

Or is that too dangerous?


#97

You would have to tell it how big to make it. Once you’ve created and formatted the image, it’s just like any other disc. You could put it in fstab if you are backing up regularly.

We could say if the destination is on ntfs, try and mount some part of the path (iteratively) and check if that is an ext partition, but automatically creating it does sound a bit scary.

I’m still not sure what happens if you try to back up to an ntfs, shared via nfs (which should fail) or ext4, shared via samba. Can’t cater for everyone!


#98

I’m getting this in my backlog:

boot is on /dev/mmcblk0p1
Backing up boot partition to /media/backup/2017-07-11/boot
There are 1 previous backups
Found latest backup at /media/backup/2017-07-10/boot
Incremental backup: copying new and changed files to /media/backup/2017-07-11/boot
rsync: link_stat "/media/ --exclude=.gvfs" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]
Making a copy of the new and changed files in /media/backup/2017-07-11/boot-delta
Cloning unchanged files from previous backup
Deleting files no longer on source
rsync: link_stat "/media/ --exclude=.gvfs" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]
Time to back up boot: 00h:00m:04s

Anything I need to be worried about?


#99

I checked, and you are right in that the boot flag was not set.
The boot partition was also empty.
I copied across the boot partition files form the backup and reset the flag to be bootable, but the backup still doesn’t boot.
What would you like me to post in way of debugging it?


#100

Not sure. If you mount your ext image, does it look like all the files in /media/backup/2017-07-11/boot are there? (ie vs /boot on the SD card). You can get a detailed comparison using diff.

Can you post the whole output for the 2017-07-11 backlog, please?


#101

It’s the LBA flag you need. RPi doesn’t care about the boot flag. Should look something like this

osmc@osmc:~$ sudo fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 29.7 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x7354d8e6

Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk0p1        8192   507903   499712  244M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      507904 62333951 61826048 29.5G 83 Linux