To save time the raspberry pi offers possibility to run a Full Backup if the pi is ONLINE! Cause the OS is running from RAM like Live Mode!
For Backup you need a USB to SDCard Reader with Adaptor Micro SD to SD, and a second SDCard i use 16GB Class 10
Plugin the new SDCard into the Adaptor and into the Reader and connect to the raspi USB Hub
Open Terminal and run Full Backup $sudo dd if=/dev/mmcblk0 of=/dev/sda bs=1M
Take a Cup of Coffee and wait..~17000sec/8GB after finish plug off the SDcard Adaptor and keep save
If you want to migrate from 8GB to 16Gb Card do a dd-dump and replace the Card inside the pi, after sucessful boot on the 16GB Card, you can allocate a fresh 8gb primary partition with $sudo fdisk /dev/mmcblk0 and do $sudo mkfs.ext4 /dev/mmcblk4 (cause noobs place it into 4!!)
Noobs Partition Layout:
A firmware upgrade will override the recovery.img on partition_1 too
Prefer a full recovery reset after a raspian version upgrade! (wheezy > jessie)
A Kernel Only upgrade can be runned with $sudo rpi-update NO OS UPDATE!
Backup can be started over SSH Login to, here you need a program called „tmux“ to hold the process online on disconnect!
Current the acd_cli tool for amazon drive mount offers no „fsid“ (device /dev) point, that you cant export and share the amazon drive at your home local network.
On the latest raspberry pi OS (jessie) you can use a small workaround to get a NFS Shared Amazon Cloud Backup Uploader (needs python3.4 !)
install acd_cli tools, create the auth file (read) and run $ sudo acd_cli mount /amazoncloud
now create a second Folder /sendtoamazon
install nfs-kernel-Server and share this Folder with NFS exports to your LAN
on the raspberrypi you can use a cron „move“ Job running every 10 Minutes:
*/10 * * * * mv /sendtoamazon/* /amazoncloud
If you now put files on the /sendtoamazon nfs share from a PC, the raspberry pi will grab and push it into the cloud via the „acd_cli mount“ a python3 script, remark 10 minutes is ok for small files! on bigger files use over „40“ minutes between pushes. If acd_cli fails check for correct python version! and last python modules!!! (python3-appdirs python3-dateutil python3-requests python3-sqlalchemy python3-pip pip3)
If you have a SMALL BANDWITH for upload you can use „rsync -avz“ instead mv (move) with „throttle“ option to upload files slowly!!
The last 12 month have been a „golden“ time of the upcomming embedded linux devices, but the custom OS’s offers some problems, you should know for projects:
embedded PC’s like the ARM based pi2 / pi3 uses a own compiled OS
not every known debian package is available
not all compile scripts to rebuild are available on git
slow performance can let you run into unuseable problems (heat, load, I/O), correct written scripts run into freezes without any error made by you!
you should take time for a closer look at buying them
calc the costs of non-x86 systems, later you cant often upgrade, cause embedded systems are not made for
dealers take too much money for less performance!
embedded devices can’t be grown up for additional precs like compression based on chips!
embedded devices need less energy, but can hangup by load over 65%, cause no cooling
the are made for learning and small control jobs
for NAS / Server jobs take x86 m-atx / micro-atx, cause you can access easy full debian packages
not all python + libs packages are available to run projects (example: acd_cli amazon cloud nas backup)
current embedded pc livetime at multimedia usage may be 24month cause to much and faster changes
May be that the arm os package trees may grow up, then we can talk again, but current x86 is the cheapest way to build systems without stress! And you have always the reserve to buildin new things of hardware..