This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Creating an image of an SD card
#1
Is there a way to create a backup image of the Tinker from a working SD card, ideally to a *.img file?

I would like to know if there is a way that I can take a good working OS configured as I want it. Then remove the SD card from the Tinker, put it into an SD reader/writer and read it and save it to an image file onto my PC or server. This so that I have a perfect image which I can easily restore when desired.

I see in windows file explorer the SD card looks like BOOT (G) with two folders extlinux and overlays.

I have searched and searched. One solution might be to use dd, but I am afraid to! I cannot find any easy solution, but I am sure that must be possible to do. Can someone point me in the right direction please.
Reply
#2
> This so that I have a perfect image which I can easily restore when desired.

The best solution is to backup your configurations and always start with the latest image.
Armbian. Lightweight Debian Stretch or Ubuntu Bionic for Tinker Board.
Reply
#3
(01-22-2019, 05:07 PM)GrahamGo Wrote: Is there a way to create a backup image of the Tinker from a working SD card, ideally to a *.img file?

I would like to know if there is a way that I can take a good working OS configured as I want it. Then remove the SD card from the Tinker, put it into an SD reader/writer and read it and save it to an image file onto my PC or server. This so that I have a perfect image which I can easily restore when desired.

I see in windows file explorer the SD card looks like BOOT (G) with two folders extlinux and overlays.

I have searched and searched. One solution might be to use dd, but I am afraid to! I cannot find any easy solution, but I am sure that must be possible to do. Can someone point me in the right direction please.


Install and use fsarchiver.  Study and practice with it.   http://www.fsarchiver.org/

You can edit and copy all of the below to a text file and name it cloneit.sh. Or just run the commands in the terminal.
Fsarchiver will make a .fsa file which is the image of a partition or all partitions in one .fsa file that can be retsored.
It will restore a large partition to a smaller partition as long as there is room for all the files. Works with any file system.
fsarchiver will only copy the files and not the empty space like dd does.
This is what you are looking for.
Clonezilla has a partition size problem and dd is verrrrrry slowwww.
You can also use yumi to make a bootable usb with a live systemrescue cd progam and use fsarchiver and gparted.
I use this script file because it is hard to remember all of the different commands. Six months from now I would be lost.
So, with this script I can refresh my memory quickly and select just the right command for the right moment.


#Create Script:
#Run kwrite, make txt file and name it cloneit.sh 
#In terminal chmod +x cloneit.sh   This will make it executable.
#In terminal run as ./cloneit.sh
#cloneit.sh will execute each line of code not commented out with the #.
#Run as ./cloneit
#Don't forget cloneit.sh must be 'chmod +x' to make it executable when first created.
#You can rename MyBoot/MyRoot or what ever you like after they have been created.
#There are two partitions named /boot and /.




#Linux Script for saving/restoring images using fsarchiver or DD.

#Saving/Cloning:
#fsarchiver usage
#Script for saving steps comment/removeComment out by removing the #.
#1 Open Terminal type lsblk and edit below devices. Run as ./cloneit.sh
#  If OS is live mounted, this script saves live and DOES NOT need to be unmounted using -A.
#2 umount devices.
    #umount /dev/sdd1   #Uncomment to use. Edit for your current devices.
    #umount /dev/sdd2   #Uncomment to use. Edit for your current devices.
#3 Save/clone the partion.      Source              Target
    #fsarchiver -A savefs  /home/~/savedboot.fsa /dev/sdd1    #This is used for live systems.
    #fsarchiver -A savefs  /home/~/savedroot.fsa /dev/sdd2    #This is used for live systems.
        #fsarchiver savefs  /home/~/savedroot.fsa /dev/sdd1        #Always source then target.
        #fsarchiver savefs  /home/~/savedroot.fsa /dev/sdd2        #Always source then target.
#Live backup with the -A   If Usb is fat32 with 4gig limitation then use -s 3000
#sudo fsarchiver -A savefs -s 3000 /media/linaro/1DBF-2257/backit /dev/mmcblk1p1 /dev/mmcblk1p2
#sudo fsarchiver -A savefs /home/linaro/savedboot.fsa /dev/mmcblk1p1
#sudo fsarchiver -A savefs /home/linaro/savedroot.fsa /dev/mmcblk1p2
       #fsarchiver savefs  /home/~/linaroS16Boot.fsa /dev/sdd1
       #fsarchiver savefs  /home/~/linaroS16Root.fsa /dev/sdd2




#Restoring:     
#fsarchiver usage.  
#lsblk>umount>edit>Run ./cloneit.sh
#1 Terminal type lsblk and edit below devices and location of .fsa files. Run as ./cloneit.sh
#2 Unmount devices.
     #umount /dev/sdd1         #Leave this uncommented.  Edit for your current devices.
     #umount /dev/sdd2         #Leave this uncommented.
#3 Restore fsa file to the partition.
      #MicroSD                  #Source              Target
#    fsarchiver restfs  /home/~/savedboot.fsa id=0,dest=/dev/sdd1          #/boot of device
#    fsarchiver restfs  /home/~/savedroot.fsa id=0,dest=/dev/sdd2          #/Root of device
#    fsarchiver restfs  /home/~/linaroRoot.fsa id=0,dest=/dev/sdd2
  
    #TBS eMMC image.  
    #fsarchiver restfs  /home/~/linaroS16boot.fsa id=0,dest=/dev/sdd1     #/boot of device      
    #fsarchiver restfs  /home/~/linaroS16Root.fsa  id=0,dest=/dev/sdd2    #/Root of device
#File naming convention.
#linaro means from a linaro computer. S16 means a tinkerboardS with 16gb. Boot is the /boot. Root is the / partition.






#dd method:
#Saving/Cloning:
#DD Clone entire disk. Target will get all partitions in the image. if=Input and of=Output.
#umount /dev/sdd1 #Use lsblk first and edit below command lines.
#umount /dev/sdd2
# dd if=/dev/sdd bs=64M conv=sync,noerror status=progress | gzip -c > /home/jay/$(date +%m%Y_%H%M%S)_linaro208_sdd32-DDimg.gz
# gunzip -c /home/jay/cloneit.gz | dd of=/dev/sdd status=progress #This restores microSD/usb/device.

#tr -d '\000' < cloneit.gz | dd of=/dev/sdd

# dd if=/dev/sdd1 | bzip2 --best > /home/~/$(date +%Y%m%d_%H%M%S)_sdd1-backup.bz2 #/boot
# dd if=/dev/sdd2 | bzip2 --best > /home/~/$(date +%Y%m%d_%H%M%S)_sdd2-backup.bz2 #/Root
#dd if =/media/324cd421-b656-4326-9882-de35a3ad335a | bzip2 /home/~/hdadisk.img.bz2
#dd if =/media/324cd421-b656-4326-9882-de35a3ad335a bzip2 of=/home/~/hdadisk.img.bz2

#Clone entire disk. Target will get all partitions in the image.
# dd if=/dev/sdd bs=64M conv=sync,noerror status=progress | gzip -c > /home/~/backupAll.img.gz
# dd if=/dev/sdd bs=64M bs=100M conv=notrunc status=progress | gzip -c > /home/~/backupAll.img.gz
# gunzip -c /path/to/backup.img | dd of=/dev/sdb status=progress
# dd if=/dev/sdd bs=64M bs=100M conv=notrunc status=progress | gzip -c > /home/~/backupAll.img.gz #This runs slower.
#To save space, you can compress data produced by dd with gzip, e.g.:
#dd if=/dev/sdf | gzip -c > /image.img
#You can restore your disk with:
#gunzip -c /image.img.gz | dd of=/dev/sdf

#You can split the disk image in to smaller pieces of any size that you specify by passing the dd #output through split command.
#dd if=/dev/sdb bs=64M conv=sync,noerror status=progress | gzip -c | split -b 50M - /path/to/#backup.img.gz.
#The above command splits the backup image file to smaller files of size 50MB or less. A two letter #suffix will be added to the files. The resulting files will have names backup.img.gz.aa, #backup.img.gz.ab, backup.img.gz.ac,...
#To join the split files into a single image file, you run the command
# cat backup.img.gz.* > backup.img.gz

#The below command restores the disk sdb from the image file backup.img.
# dd if=/path/to/backup.img of=/dev/sdb status=progress
#To restore from a compressed backup image, use the gunzip command with dd
# gunzip -c /path/to/backup.img | dd of=/dev/sdb status=progress
#To restore from a backup image that is compressed and split, run:
# cat backup.img.gz.* | gunzip -c | dd of=/dev/sdb status=progress






#DD method for restore:
#DD lsblk>umount>edit>run ./cloneit.sh
#Note: if=Input and of=OutPut Warning DD=DiskDestroyer
#Clone device as a compressed image
#dd if=/dev/sdd1 | bzip2 --best > /home/~/$(date +%Y%m%d_%H%M%S)_sdd1-backup.bz2 #/boot
#dd if=/dev/sdd2 | bzip2 --best > /home/~/$(date +%Y%m%d_%H%M%S)_sdd2-backup.bz2 #/Root
# dd of=/dev/sdd1 if=/home/~/savedImageFile.img #Restore /boot
# dd of=/dev/sdd2 if=/home/~/savedImageFile.img #Restore /Root

# Use gunzip to restore a compressed image.
# gunzip -c /path/to/backup.img | dd of=/dev/sdb status=progress
#Note:
#Run as /cloneit.sh
#Don't forget cloneit.sh must be 'chmod +x' to make it executable when first created.
#Take note of the i is not l and the 0 is not o.
#id,dest,mkfs,mkfsopt,uuid,label you will see this if the id or dest is wrong.
#https://www.opentechguides.com/how-to/article/centos/171/linux-disk-clone.html
#https://serverfault.com/questions/141283/how-to-clone-a-usb-flash-drive-using-dd
#https://serverfault.com/questions/4906/using-dd-for-disk-cloning







#Create Script:
#Run kwrite, make txt cloneit.sh chmod +x and run as ./cloneit.sh
#cloneit.sh will execute each line of code.
#Run as ./cloneit
#Don't forget File.sh must be 'chmod +x' to make it executable when first created.
#You can rename MyBoot and or MyRoot after they have been created. These are your backups.







#Initial setup for a new microSD:   
#microSD 16gb or be carefull with the eMMC TinkerboardS. I only made a backup image of both partitions and another one full.
#1 Use gparted to make 3 partitions as below or only 2 works.  
#  Make /boot size 64mb and / can be all of the space left over.
#    Empty 4mb         /boot 64mb                  /
#     0-8191          8192-139263      139264-30777343  total 30638080   
#                     /dev/mmcblk1p1       /dev/mmcblk1p2 or /dev/sda1 /dev/sda2
   
#2 Format microSD /boot with fat32
#    sudo mkdosfs -F 32 -I /dev/sdc1  
#3 Format microSD / with ext4




#commands:
#lsblk sudo fdisk -l sudo ls /dev demesg | tail
#mount umount
#lsblk -a lsusb -v cat /proc/partitions
#lshw hdparm -i /dev/sda hwinfo lspci uname -a dmidecode -t memory
#df -disk space of file system
#free -check ram cat /proc/cpuinfo cat /proc/meminfo cat /proc/version
#cat /proc/scsi/scsi

#FileSystemCheck >lsblk>umount drive then sudo fsck -fy /dev/sda1
#Sata file system check/repair if shutdown not done right. Must be umounted.
# sudo /sbin/fsck.vfat /dev/sde1 or sudo /sbin/fsck.ext4 /dev/sde2
#End
Reply
#4
Clonezilla will do its own backup, within several other backup programs. But if it's expected to clone the SD card then dd is the preferred. The only drawback it will occupy the same SD card size. So for gaining some space, it would be most efficient if piped to a packer, like 7zip or xz Wink

I used to do
Code:
$ sudo dd if=/dev/<kernel_name> | xz >file_to_save.xz
The reverse it would be
Code:
$ sudo xzcat file_to_save.xz >/dev/<kernel_name>

Even cat it might be use instead of dd.

Not tested, try on your own experiments
Light blue words might be a link. Have you try to click on them? Big Grin
Reply
#5
> The only drawback

Besides there is no integrity checking. You need to conduct at least two readings and do compare them.
Armbian. Lightweight Debian Stretch or Ubuntu Bionic for Tinker Board.
Reply
#6
Yesterday, I tried Win32Diskimager. The UI is a little counter-intuitive. But I found that it is possible to read the Tinker SD card and to create an .IMG file. However, I tried burning another SD card, unfortunately, it did not work. The other issue is that it took 1 1/2 hrs to save the Tinker SD card, producing a 64GB .IMG file.
So it seems to have worked, but surely there is a way to just read the required files and not the whole 64GB space, most of which is empty.

Anyway, I ordered a 32GB Samsung EVO+ SD card, I couldn't find a fast 8GB one.
Reply
#7
(01-23-2019, 10:18 AM)GrahamGo Wrote: Yesterday, I tried Win32Diskimager. The UI is a little counter-intuitive. But I found that it is possible to read the Tinker SD card and to create an .IMG file. However, I tried burning another SD card, unfortunately, it did not work. The other issue is that it took 1 1/2 hrs to save the Tinker SD card, producing a 64GB .IMG file.
So it seems to have worked, but surely there is a way to just read the required files and not the whole 64GB space, most of which is empty.

Anyway, I ordered a 32GB Samsung EVO+ SD card, I couldn't find a fast 8GB one.


I done it all.  Fsarchiver is the best one of all. My opinion only.
I am logged into my desktop and I just made an image of it live. It made a 3.7gb image file of 16gb tinkerboardOS eMMC.

https://forum.antergos.com/topic/6406/sy...e-backup/4
Reply
#8
(01-23-2019, 07:43 AM)igorpec Wrote: Besides there is no integrity checking.
Thank you to point it out.
But what is your packaging method ?

The image is just the media clone. So we can mount it after unpacking.
@ OP
It might be convenient to shrink the partition(s), so the data will occupy only a portion of the media. To handle with the partition would be simpler by gparted, or the counterpart parted from a CLI.
From there you might opt to reduce the data to be copied. It should take to read a bit the man page about count=.


Anyways, as I suggested, fsarchiver will do its best to copy the necessary data and move across different partition sizes. It won't be much portable as it is for a media clone, but it will just move the minimal data. The only thing that it won't do is to copy the u-boot which is outside any partition, so to complete the task (to move the system to a different media) it might take to use dd only for those few megabytes reserved to u-boot.
Light blue words might be a link. Have you try to click on them? Big Grin
Reply
#9
Anyways, as I suggested, fsarchiver will do its best to copy the necessary data and move across different partition sizes. It won't be much portable as it is for a media clone, but it will just move the minimal data. The only thing that it won't do is to copy the u-boot which is outside any partition, so to complete the task (to move the system to a different media) it might take to use dd only for those few megabytes reserved to u-boot.
[/quote]


I just ran across G4L (Ghost for Linux).
Is this one good for cloning?
Clonezilla copies that u-boot thingy.  Maybe this G4L will work better than clonezilla.

Update:
Easier to just do the following:
1 Flash a microSD with etcher.
2 Then use DD or fsarchiver for restoring / with a previous created image of a fully configured / system.
3 As Im4Tinker has said if the eMMC or microSD is not recognized you will have to use his DD procedure.

G4L did restore a large 32gb image to a 16gb microSD.
1 Used gparted to reduce / partition to size of files from 28gb to 4.5gb with very little empty space.
2 Used G4L to create an image from the 32gb microSD.
3 Used G4L to restore to 16gb.
4 Used gparted to delete/format /. This is faster than resizing the / partition back to it's fullest size.
5 Used fsarchiver or DD to restore another image to / which has the full 8gb sized /.
Note: G4L got to 99% and hung up. I waited about 10 minutes and ctrl/alt/del to reboot.
The 16gb microSD did boot up on tinkerboard and worked.
G4L created from the image the 4mb with the UMS/u-boot and the /boot and the /.
It would be easier to just flash the microSD with etcher and use DD or fsarchiver for restoring /boot and /.
As Im4Tinker has said if the eMMC or microSD is not recognized you have to use his DD procedure.
It is the only hope you have. U-boot is hidden inside the first 4mb of an unallocated space. How that works I have no idea.




I got a question. How can the u-boot code be written in an unallocated 4mb and why?
Why not stick it in the /boot? That would make it much easier to deal with.

I guess that is a complicated question.
https://boundarydevices.com/u-boot-usb-m...ge-gadget/
Reply
#10
> The image is just the media clone.

Yes, but the flash media quality is always questionable.
Armbian. Lightweight Debian Stretch or Ubuntu Bionic for Tinker Board.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)