Google Drive Backup using Rclone

For 8 TB of data storage on Google Drive, plus my own Google organization, I am paying £30/month, which is a pretty good deal.

I wanted to use this space for backing up my NAS, but it was proving difficult. The program I was recommended for Linux backup, Duplicati, was not the best for this purpose. My backup runs would not complete, they would be slow, and full of syncing errors.

Until I discovered rclone.

rclone was much better than Duplicati at backing up my NAS to Google Drive.

This is the script I use to sync the NAS content to Google Drive: https://github.com/wordswords/dotfiles/blob/568a8768154de8609a01b26560373ec5ca0eab85/bin/rclone-backup.sh

It works just like rsync, but with a progress indicator. I’ve added it to my crontab and it syncs everything up weekly.

Setting up Kindlefire HDX for Development under Ubuntu 12.04

amazon_kindle_fire_hdx1

I wanted to get a Kindlefire HDX running under Ubuntu 12.04 with adb.

First I needed to setup the udev rules:

1. Edit /etc/udev/rules.d/51-android.rules as root, and add the following line (create this file if it does not exist):

SUBSYSTEM=="usb", ATTRS{idVendor}=="1949", MODE="0666"

2. Change the permission of this file by executing the following command as root:

chmod a+r /etc/udev/rules.d/51-android.rules

3. Reload the rules by executing the following command as root:

udevadm control --reload-rules

4. Run these commands to restart adb:

adb kill-server
adb start-server

5. Now when I run

lsusb

I can see the device listed.

6. Next I needed to enable adb access on the Kindlefire HDX device itself by going to Settings -> Device -> Enable ADB.

7. Finally I could run:

adb devices

within Ubuntu and have it recognise the Kindlefire HDX.

How to remove nano, vim and other editors’ backup files out of a directory tree

gardening for science..

Linux command-line editors such as nano and vim often, by default, create backup files with the prefix of “~”. I.e, if I created a file called /home/david/myfile, then nano would create a backup in /home/david/myfile~. Sometimes it doesn’t delete them either, so you’re left with a bunch of backup files all over the place, especially if you’re editing a lot on a directory tree full of source code.

Those stray backup files make directory listings confusing, and also add unnecessary weight to the commits on source control systems such as svn, cvs, git.. etc. If you’re working on a programming team with other people, then it causes further problems and confusion, because person A’s editor can accidentally load person B’s backup file.. etc etc. Nightmare.

So instruct your editor, or the programming team you’re working with, not to drop these backup files. You can configure most editors to change the place where the editor drops its backup files, so you could store all your backup files in a subdirectory of your home directory, for example, if needed. However I always set my editors not to leave backup files about.

Once you know that new backup files will not be created, view the current list of backup files, along with the user that created them.. so you know who’s been creating the backup files and when, etc:

find . -name '*~' -type f -exec ls -al {}  ;

Then archive the stray backup files, with this command:

find . -name '*~' -type f -exec mv -i {} ./archived-backups ;

That will find all backup files in the current directory and below, and move them all to a subdirectory in the current directory called ‘archived-backups’. This is a fairly safe find/exec command, because with the -i switch, mv will not ‘clobber’. This means If you have two backup files, one in /opt/code/index~ and one in /opt/code/bla/bla/index~, they will not ‘clobber’, or overwrite each other automatically when moved into the new directory. You will be informed of any conflicts present so you can resolve them yourself.

However in practice I usually omit the ‘-i’ switch and let them clobber each other, because I usually end up deleting the ./archived-backups/ directory very quickly after that anyway.