anik
Posts: 15
Joined: Tue Jul 09, 2013 7:43 pm

Backing up the SD card - what's difference .bin vs. .img?

Tue Jul 09, 2013 8:11 pm

It seems that most Raspberry Pi operating system and projects are distributed as .img files. And I have read that if I want to backup my SD card to an .img file I could do it using a program called Win32DiskImager as described elsewhere in this forum. However, I do not have a Windows box. I have a Ubuntu desktop box with a card reader and have read in several places (including here) that I can use the linux dd program, but it only creates .bin files. So my questions are:

1. Is there any practical difference between making a .bin file or an .img file to use as a backup? I am completely new at this so if my SD card does fail or become corrupted, or I make some dumb mistake and erase something valuable, I need to be able to restore it easily and quickly. Is either format preferable for that purpose?

2. If .img is the preferred format, is there any way to create an .img file using dd or any other tool under Ubuntu linux? Or, alternately, can a .bin file be converted to an .img file and would there be any advantage in doing so?

3. Some sites tell you to add a block size parameter (bs=1M) when making a backup using dd. Is that good or bad advice?

4. Is there any way to do a backup that will produce an .img (or .bin, if they are equivalent) file that does not require removing the card from the Raspberry Pi? Ideally I'd like to run it once a week automatically (I'm guessing that could be done as a cron job?) in the middle of the night and then at a more convenient time copy the backup file to another machine on the network.

If you can answer any or all of these it would be VERY helpful to me, and maybe to some other new users.

smithg400
Posts: 148
Joined: Sat Dec 24, 2011 3:37 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Tue Jul 09, 2013 10:03 pm

Hi Anik,

1. Both win32diskimager and dd create exact bit for bit copies of the sd card. Neither does anything to the image (e.g. no compression) and nothing is added or taken away - if you ran both tools to take a copy of an sdcard and then compared the two files, they (should) be identical. The .bin and .img extensions are just conventions and you could call then anything you like. i.e. you can use dd to create a .img file - it is just a name.

2. As the files are identical there is no need to convert them. A rename will do the job!

3. The 'bs' option to simply tells dd how much to read and write at one go - by default it reads 512 bytes at a time - so to copy the sdcard it reads 512 bytes from the sdcard to a buffer in memory - it then writes the 512 bytes to disk, then it reads another 512 bytes from sdcard and then writes that. If you specify bs=1M it will read 1Mbyte to internal memory and then write that out to a file, then read another 1Mbyte and so on. Typically 1 read of 1Mbyte is quicker than 2048 reads of 512 bytes so using bs=1M simply speeds things up at the cost of making dd use more memory for its buffer.

4. You can copy the sdcard while the Pi is running, but you are copying a live filesystem and the filesystem is changing while you are copying it. So you can (will) end up with a copy that isn't consistent. Were you to copy the 'backup' back to an sdcard later you'd probably find that it would want to do a filesystem check to repair the filesystem(s) when you started the machine and there is a possibility it couldn't repair them - so not an ideal way to backup. There are ways to backup files from a live filesystem - but doing dd to copy the raw sdcard isn't the way!

Hope that helps
Graham

Joe Schmoe
Posts: 4277
Joined: Sun Jan 15, 2012 1:11 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Tue Jul 09, 2013 11:44 pm

Re #4, while you are technically right (and, I suppose, that means that is the answer you should give to a newbie), the fact is that, in practice, it rarely matters. I do it all the time and haven't had a problem.

Especially if you do it at an off-hours time, when there isn't any other (real, business-oriented) processing going on.

And, as you say, at worst, you'll have to do an fsck as part of the first boot after a restore. No biggie.
And some folks need to stop being fanboys and see the forest behind the trees.

(One of the best lines I've seen on this board lately)

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 12:36 am

I agree with Joe. If you dd a live writable filesystem, using ext4, then anything not sync -ed to disk/SD before starting the dd may be lost. It really depends on the superblock writes, after the journal has been written. You may end if with an inconsistent disk, but if you mount the .img file you can run an fsck on it and fix the image. The FAT partition is not written to often, but do a sync before the dd.
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

anik
Posts: 15
Joined: Tue Jul 09, 2013 7:43 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 1:59 am

Thank you all for these replies, that explains it to me. I did not realize that .bin and .img files are the same!

Now, if I may ask a follow-up question, in particular to Joe Schmoe, but if anyone else knows please feel free to chime in. Joe, you said that you do a backup from the Raspberry Pi all the time, and I assume you meant using dd. May I ask exactly what dd command you use? And do you run it manually or as a cron job? I ask this because all the pages I have seen so far on the subject appear to assume you have removed the card from the Raspberry Pi and taken it to another computer to back it up, so it would be very helpful to know the exact syntax that should be used to invoke a backup on the card itself, particularly from someone that has actually done it and knows it works.

Thank you again, much appreciated!

smithg400
Posts: 148
Joined: Sat Dec 24, 2011 3:37 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 6:19 am

I agree - generally you'll get away with doing a backup of a live filesystem like this (especially if the machine is 'quiet' at the time), either because it just works or because fsck 'sorts it out' - but I've had previous instances where fsck fails to solve the problem so it isn't 100% guaranteed (but 99.9% may be good enough).

When backing up your sdcard on a linux PC you are probably entering a command like

Code: Select all

dd if=/dev/sdb of=backup.img bs=1M
which will backup the device sdb to the file backup.img (you may have used sdc, sdd or something similar depending on what device your card reader is mapped to). The command on the Pi is the same, you just need to know that the sdcard is accessed as device mmcblk0 and, of course, you'll need to write the image to some other storage device either attached via USB or mount across the network. So the command will be something like

Code: Select all

dd if=/dev/mmcblk0 of=/path-to-your-storage/backup.img bs=1M
Of course you'll probably want to do this as the 'root' user so add a sudo to the front of the command (or become root by other means).

Personally I'd use a simple script something like this:

Code: Select all

#!/bin/bash
cd /path-to-your-storage
rm backup2.img
mv backup1.img backup2.img
mv backup0.img backup1.img
dd if=/dev/mmcblk0 of=backup0.img bs=1M
and then run that as a root cron job. That will keep 3 backup files for you (with backup0.img as the most recent) - then if you were ever to have a problem you can always go back to the previous one!

User avatar
DetlevSchm
Posts: 72
Joined: Tue Mar 12, 2013 8:43 am
Location: 3rd planet

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 7:33 am

jackokring wrote:You may end if with an inconsistent disk, but if you mount the .img file you can run an fsck on it and fix the image.
'Repair' just restores consistency from the viewpoint of the file system.

'dd' reads blocks from the source device into memory and transfers them to the target device.

Say, it has just read block no. 13 and then a file with content "Hello world" is created. "Hello" goes to block 13 and "world" to block 14. Then block 14 is processed.

'fsck' can restore consistency by eliminating the corrupted file, but cannot retrieve "Hello".

Joe Schmoe
Posts: 4277
Joined: Sun Jan 15, 2012 1:11 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 12:20 pm

I agree with (most of) what has been posted. In particular, yes, there is a risk of missing "the last file" - but, as noted a few times already, that's not that big a deal in most cases, and the risk of it is minimal if you run the backup by the light of the moon (when the system is "quiet").

A couple of other notes:

1) You can use "cp" instead of "dd" - the syntax is a little less fiddly. I.e.:

Code: Select all

cp /dev/mmcblk0 /path/to/file.img
(I haven't tested this recently, but I used to use that syntax in the old days to image and/or copy floppy disks [remember those?]. I'm pretty sure that 'cp' handles the blocksize issue intelligently, so you don't have to specify it - as you do with 'dd')

2) For that matter, you could also use "netcat". I've used something like:

Code: Select all

netcat -l -p 2000 > /dev/hda
on one machine and:

Code: Select all

netcat othermachine 2000 < /dev/hda
on the other - to "clone" a machine over the network. Something similar should work for backing up the SD card.
And some folks need to stop being fanboys and see the forest behind the trees.

(One of the best lines I've seen on this board lately)

anik
Posts: 15
Joined: Tue Jul 09, 2013 7:43 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 5:27 pm

Thank you again for all the responses, I am learning a lot from this discussion. One thing that seems obvious after reading the most recent posts is that it would be better for the backups to go to some other place on the local network. On the distribution I am using samba is not fully configured, and I have no desire to get into that, but ssh is working fine. I know that on a Mac there is a program that you can use (MacFusion) that will mount or unmount a location on another machine as long as you can ssh into it. I wonder if there is a way to do something like that from within a bash script on the Raspberry Pi? Basically what I think I would need to do is temporarily mount a particular directory on another machine, and then do the dd to a file at that location, but the trick would be to not have dd try to back up the contents of the mounted director along with the SD card. I don't know if it would do that or not, I really don't know that much about how Linux does this sort of thing.

I'm really not sure how to pull this off. :idea: Joe Schmoe says you can use cp instead of dd, but would that yield exactly the same result? And if so, does that imply that you could use scp to make the copy across the network? If that is the case, would something like this work?

scp /dev/mmcblk0 [email protected]_address:~/path/to/file.img

Note the above assumes that the user only has access to their home directory on the destination machine, therefore the destination path is relative to that, and also assumes that the user has set up ssh login using ssh keygen rather than passwords so that any bash script wouldn't have to deal with entering a password - I am assuming that can be done on a Raspberry Pi though I have not yet attempted it.

You guys are the experts here, so I am asking, would using cp (or scp) instead of dd result in the exact same file being copied? If so, that would make things a whole lot easier!

EDIT: And if it would work, I wonder if there a way to make the bash script exit gracefully if the scp command fails for some reason.

User avatar
RaTTuS
Posts: 10498
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 5:34 pm

dd if=/dev/mmcblk0 of=/path-to-your-storage/backup.img bs=1M conv=sync,noerror
sync and noerror are useful
you can also use rsync to backup the running image to a remote system location
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

anik
Posts: 15
Joined: Tue Jul 09, 2013 7:43 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 5:58 pm

RaTTuS wrote:dd if=/dev/mmcblk0 of=/path-to-your-storage/backup.img bs=1M conv=sync,noerror
sync and noerror are useful
you can also use rsync to backup the running image to a remote system location
What does "conv=sync,noerror" do?

Why would using rsync be preferable to using scp, and what would the syntax of the rsync command be?

I'm just asking because I have never used rsync, however if it is preferable for some reason I'd be happy to use it, but just need to know the syntax.

I'm sort of trying to avoid using dd because it appears (and this may be just my ignorance) that it has to first back up to a local volume, so you would need to have a memory stick or some other external storage device connected to the RPi, whereas by using scp (if it is actually possible to use that in this way) you can copy directly to a volume on another system. I just don't see any way to do that using dd, and that's what is confusing me here.

User avatar
DetlevSchm
Posts: 72
Joined: Tue Mar 12, 2013 8:43 am
Location: 3rd planet

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 6:23 pm

anik wrote:What does "conv=sync,noerror" do?

Code: Select all

man dd
anik wrote:Why would using rsync be preferable to using scp, and what would the syntax of the rsync command be?

Code: Select all

man rsync
You get the meaning of 'man'? :-)

User avatar
RaTTuS
Posts: 10498
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 6:29 pm

dd
noerror will not stop on a error
sync will sync the block to be filled with 0s
i.e if you have a problem reading a block - then don't stop carry on and fill the error with 0

rsync
look for examples here or via google
rsync -vax / [email protected]:/remote/directory
will copy only changed files and not traverse file systems [so you could mount an external HD and rsync to that locally]

v = verbose
a = all
x don't traverse file systems
from memory I may be wrong as I'm in the pub
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

anik
Posts: 15
Joined: Tue Jul 09, 2013 7:43 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 6:52 pm

DetlevSchm wrote:
anik wrote:What does "conv=sync,noerror" do?

Code: Select all

man dd
anik wrote:Why would using rsync be preferable to using scp, and what would the syntax of the rsync command be?

Code: Select all

man rsync
You get the meaning of 'man'? :-)
Would you please do me a huge favor and refuse to reply to any message I post in the future? If all you can suggest is reading man pages, that means you don't really want to be helpful. We are having a conversation here and people are learning things, and I have never yet come across a man page that was decipherable by the average non-geek human. And I really, really, really DO NOT want any help from you if reading man pages is all you can offer.

Sorry if this comes across as offensive but it is one reason I have pretty much sworn off of using IRC to get help - there's always one or two (expletive deleted) types that cannot lift a finger to help without criticizing someone for not reading man pages or other documentation, and the funny part is they never ask beforehand if the person has done that, they just assume they haven't (and you know what they say about assume). I have spent hours looking at documentation in the last two days, but in this case I was responding to a post from someone (NOT YOU) that was injecting something completely new in the mix, and I was trying to understand why he was doing that. Implied in the question was why he thought those options might be necessary, and reading a man page (even if you can understand the damn thing) would not tell me that.

This is just something that really ticks me off about help forums, and I actually got banned from an IRC forum once for swearing at a guy for bashing me for not reading documentation when I had just spent about six hours doing exactly that, and got nowhere. So this is a very sore point with me and I just wish you would save us both some grief and not reply to my posts if that is the sort of comment you are going to make.

anik
Posts: 15
Joined: Tue Jul 09, 2013 7:43 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 7:01 pm

RaTTuS wrote:dd
noerror will not stop on a error
sync will sync the block to be filled with 0s
i.e if you have a problem reading a block - then don't stop carry on and fill the error with 0

rsync
look for examples here or via google
rsync -vax / [email protected]:/remote/directory
will copy only changed files and not traverse file systems [so you could mount an external HD and rsync to that locally]

v = verbose
a = all
x don't traverse file systems
from memory I may be wrong as I'm in the pub
Thank you. I guess what I should have asked is why you think those options (noerror and sync) are necessary or desirable in this case. I only ask because I have seen at least a dozen pages giving examples of how to use dd and none of them used those options, but maybe you know something they don't?

As for rsync, I'm not understanding that at all. Did you perhaps mean to use /dev/mmcblk0 instead of the first / in that line? And I guess I'm still trying to figure out why rsync would be preferable to scp - granted it supposedly only transfers changed files, but in this case we're not doing a file-by-file copy anyway, we're backing up the entire SD card, so would that not appear to be one huge file that's always going to have changed between backups? Or am I totally missing something here?

By the way, I apologize if I seem a bit terse here, I'm still ticked off by DetlevSchm's reply and it's going to take me a while to calm down.

User avatar
DetlevSchm
Posts: 72
Joined: Tue Mar 12, 2013 8:43 am
Location: 3rd planet

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 7:43 pm

anik,

I apologize, if I have opened an old wound, I did not know your background.

As for my suggestions, I was under the impression, that you do not know, that 'man' exists.

'Reading' a man page does not mean, one has to read it from a to z, nobody does that.

The parameters you asked for can be found via the slash command and lead to a one sentence description each, and the benefits of rsync are stated in the one paragraph description.

Just try to be aware, that not everyone, who utters 'documentation', is your mortal enemy.

Again, I apologize, if I have caused you any stress.

(and I will not put you on my dislike-list :-) )

anik
Posts: 15
Joined: Tue Jul 09, 2013 7:43 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 9:04 pm

DetlevSchm, I also apologize if I am a bit touchy. The fact is that I have no prior experience with a Raspberry Pi other than helping someone install Raspbmc, which is pretty much a turnkey thing - one of the easiest installs I have experienced, really. But now I am trying a different project and nothing is going right - even when I think I have all the kinks hammered out, some new issue pops up, And up until yesterday I did not really realize that SD cards were not all that reliable - I had probably heard it before a few times, but it never really clicked. So it somehow became kind of important to me to figure out a way to easily back this thing up, and with all the other issues I've had to work through I just didn't really want to spend another several hours just trying to learn how to copy a file.

I think we have all been there - tired, frustrated, and searching the internet in the hope you'll find someone else that's had to do what you want to do and has taken the time to document it, so you don't have to reinvent the wheel. I really only get annoyed when I ask a question that could probably be answered with one or two lines of example script or code or whatever, and instead get referred to man files. I have a deep hatred for man files because they were written by geeks, for geeks, and they go on and on about all the various options but only very rarely do they give actual examples, and even less frequently an example of what I want to do. Keep in mind that by the time I am desperate enough to turn to a man page, I've already searched the web and probably encountered all of the common usage patterns (whether I actually understood them is another matter entirely). Anyway, man pages are likely part of what drives people to use Windows and OS X - at least the documentation they have can usually actually be understood by users.

As for rsync, when I type "man rsync" into the RPI's command prompt it replies "No manual entry for rsync", whereas I do get a man page for scp. So it appears that scp is already installed, and rsync isn't (doing "which rsync" confirms this). Remember that I am only copying a file across a local network in the middle of the night. When I looked up the man file online, it said:
Description

Rsync is a fast and extraordinarily versatile file copying tool. It can copy locally, to/from another host over any remote shell, or to/from a remote rsync daemon. It offers a large number of options that control every aspect of its behavior and permit very flexible specification of the set of files to be copied. It is famous for its delta-transfer algorithm, which reduces the amount of data sent over the network by sending only the differences between the source files and the existing files in the destination. Rsync is widely used for backups and mirroring and as an improved copy command for everyday use.

Rsync finds files that need to be transferred using a lqquick checkrq algorithm (by default) that looks for files that have changed in size or in last-modified time. Any changes in the other preserved attributes (as requested by options) are made on the destination file directly when the quick check indicates that the file's data does not need to be updated.


None of that is the slightest bit useful to me in this situation, IF scp will work just as well. The question I asked was whether scp would work at all in this application, and the whole side trip into rsync is really just a distraction for me at this point. It may be like suggesting the use of an air socket when all you really need is a common hand wrench, and you've never learned how to use an air socket. Sure it may be less efficient, but given the task at hand, I don't care. The question I really wanted to have answered, if anyone knows, is "will scp produce the same file that dd would?" In other words, could I use scp to copy the entire SD card to an .img file, and then later, if I have to, use dd to copy that .img file back to the card. Or would scp produce a different file than dd would?

Some people would probably say that if rsync is better they want to learn how to use it. And maybe I would, if I were not so tired and frustrated, but the truth is that if scp will produce exactly the same output as dd, then rsync holds no benefit for me. And if rsync does NOT produce the same output as dd, then it is of no benefit to me. The only way rsync would be useful to me here is if it produced the same file that dd would, whereas scp would produce something different, and I have my doubts that this is the situation.

In any case this may all be moot because it looks like the use of the SD card in the Pi is going to make this project too unreliable, plus we've had some unexplained glitches. So we may be going back to the way we used to do it, which is known to work and does not involve the Pi. I hate to essentially have wasted a week of my life on this but sometimes you just have to cut your losses. So if I don't post anything else in this thread, it's likely because we abandoned the project, not because of anything that has been said by you or anyone else. To everyone in this thread, thank you for all the help and suggestions, and please forgive me for being cranky and tired.

Joe Schmoe
Posts: 4277
Joined: Sun Jan 15, 2012 1:11 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 10:57 pm

anik, below are a few comments about miscellaneous points raised in this thread. But first, note that if someone here annoys you (DetletSchmm), don't bother arguing with them - just killfile them and be done with it (On this board, the "killfile" functionality is called "foe" - the easiest way to use it is to find a post by the offender, and right click on their name on the right - then follow the prompts to making them a "foe")

Anyway...

1) Yes - "cp" and "dd" will create the exact same file. And, as I said, the syntax for "cp" is easier, so there' s really no need to use "dd" for this task (or any tasks related to the making or saving of images for the Pi). Note to nitpickers: I didn't say there's no reason to use "dd" ever - there are - but not in this simple case.

2) No, you can't use "scp", because "scp" refuses to work with anything other than an ordinary file. You can't use device names with "scp".

3) You don't need to install samba on the Pi for this. All you need is an available share somewhere on your network (say, on your Windows box) that you can access from the Pi. The functionality to attach to a share is built-in - doesn't require any installs or any configuration. Just do something like:

Code: Select all

mount //machine/share/...  ...
Note: Others will tell you that NFS is even better - but it is harder to setup and doesn't interoperate with Windows.

4) About "rsync". There is a basic disconnect in the area of "How do I backup my Pi?" between the "image" methods and the "by files" methods. I won't go into a full discussion, but suffice to say that there are a lot of technical limitations with the "image" methods, but most people give "image" method answers on the forum, for a variety of personal reasons (which, again, we won't go into here). Anyway, the discussion of using "rsync" was in the context of doing a "by files" type of backup, which is far superior (technically) to the "image" based methods, but is, alas, a bit newbie-unfriendly. So, unless you are interested in going this route (that is to say, that you are content to stay with "image" based methods), you can safely ignore the "rsync" discussion.

(More later if I think of them...)
And some folks need to stop being fanboys and see the forest behind the trees.

(One of the best lines I've seen on this board lately)

Joe Schmoe
Posts: 4277
Joined: Sun Jan 15, 2012 1:11 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Wed Jul 10, 2013 11:01 pm

One more comment:

The tactic of responding "man XXX" to any request for help is a long and time-honored tradition in the Unix help community. It isn't going away - unless/until Unix itself goes away.

As sad as it is, I have to say: Get used to it.
And some folks need to stop being fanboys and see the forest behind the trees.

(One of the best lines I've seen on this board lately)

anik
Posts: 15
Joined: Tue Jul 09, 2013 7:43 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Thu Jul 11, 2013 1:43 am

Joe Schmoe wrote:1) Yes - "cp" and "dd" will create the exact same file. And, as I said, the syntax for "cp" is easier, so there' s really no need to use "dd" for this task (or any tasks related to the making or saving of images for the Pi). Note to nitpickers: I didn't say there's no reason to use "dd" ever - there are - but not in this simple case.

2) No, you can't use "scp", because "scp" refuses to work with anything other than an ordinary file. You can't use device names with "scp".
Why is it the simple method never works? :roll: Thanks for clarifying that for me, if we do decide to try to carry on with this I might have wasted a lot of time trying to make scp work.
Joe Schmoe wrote:3) You don't need to install samba on the Pi for this. All you need is an available share somewhere on your network (say, on your Windows box) that you can access from the Pi. The functionality to attach to a share is built-in - doesn't require any installs or any configuration. Just do something like:

Code: Select all

mount //machine/share/...  ...
Note: Others will tell you that NFS is even better - but it is harder to setup and doesn't interoperate with Windows.
Turns out that using mount isn't quite that simple either. To make a long story short, I found I had to do this:

sudo apt-get update
sudo apt-get install cifs-utils

Then only after that was installed, I could do this:

mount -t cifs //local_ip_address/share_name/ /mnt/ -o username=home/username,password=secret

And when finished, to unmount it:

umount /mnt/

Where:

local_ip_address is the IP address of the machine
share_name is the first level share name, and I could drill further down into the directory if desired
username is the user name for the share
secret is the share password (in plain text :( )

This was just a quick test (well, not so quick because I had to figure out the syntax for mount, and then why it wouldn't work at first) but it seems to work fine now, although it's a bit unnerving that the share appears in the /mnt directory rather than something not quite so generic. But I guess that really doesn't matter as long as I can mount the proper share, do the cp or dd, and then umount it.
Joe Schmoe wrote:4) About "rsync". There is a basic disconnect in the area of "How do I backup my Pi?" between the "image" methods and the "by files" methods. I won't go into a full discussion, but suffice to say that there are a lot of technical limitations with the "image" methods, but most people give "image" method answers on the forum, for a variety of personal reasons (which, again, we won't go into here). Anyway, the discussion of using "rsync" was in the context of doing a "by files" type of backup, which is far superior (technically) to the "image" based methods, but is, alas, a bit newbie-unfriendly. So, unless you are interested in going this route (that is to say, that you are content to stay with "image" based methods), you can safely ignore the "rsync" discussion.
Well here is the thing about that. I have NEVER been able to successfully restore a system from a backup that uses file-level copies, with one exception which I will mention momentarily. In every case where I have ever tried it, the system simply would not boot and I had no idea how to fix it. So the idea of being able to take a known good install, save it to one huge backup file, and the copy it down to the same or a different SD card (of the same size) is very appealing. Plus, you would not run into all the issues with "files that aren't really files" (symlinks?). Bear in mind that Linux in not my primary operating system, so when something won't boot it's pretty much "game over" for me.

The one thing I have successfully used in the past, and actually it really shocked me that it worked so well when I had to restore from a backup, is something called Mondo Rescue. While Mondo Rescue appears to copy files (though I am not at all sure about that, so don't quote me) it is very fast. But as far as I know, there is no version that will run on a Raspberry Pi, and it does not produce .img (or .bin) files. And honestly, since we're dealing with a SD card, I'm not sure it would have any advantage over cp or dd.

I have no doubt that rsync might have its advantages for people who, when confronted with a non-booting system, know how to do anything other than reformat the drive and reinstall the operating system from scratch. I am not one of those people. So my feeling is that if I have a card that won't boot, for whatever reason, and I have an .img file that contains a recent backup that I can restore using dd, I am light years ahead of having nothing at all.

From your other post...
Joe Schmoe wrote:One more comment:

The tactic of responding "man XXX" to any request for help is a long and time-honored tradition in the Unix help community. It isn't going away - unless/until Unix itself goes away.

As sad as it is, I have to say: Get used to it.
Well, all I will say about that is that is exactly the sort of behavior that drives some people to Windows or OS X, and insures that Linux will never be a major operating system (at least on the desktop. When it comes to tablets and small computers, that's another thing altogether). I can't tell you how many times I have heard complaints about how unfriendly Linux people are in online forums. I realize that's not the majority, but when you encounter even one such person it tends to leave a lasting impression, and it certainly has on a few folks I've talked with.

I did, however, hope that such would not be the case in a Raspberry Pi forum, if only because the original intent for the creation of the RPi was to get kids interesting in programming, and if adults have trouble with those man files, I can only imagine how most kids would feel about them. I'm not talking about the rare kid who starts programming in Linux in fourth grade - as I said, man pages are written by programmers for programmers, and if you think like a programmer then you might actually be comfortable with the format of man pages. But most everyone else learns a lot more from an example followed by an explanation - that is, you show an actual working example, then explain what each of the options do and why you might need those options. Then once people get the general concept, you might present the list of all the options. If you have ever read a popular technical book from a successful publisher, you will see that they are nothing like man pages, and there is a reason for that.

Anyway, the other side of that is that when someone simply says "read the man page" or "read the documentation", to me that's like saying "I can't be bothered to answer your question so I will just insult you." I could understand that response if I were asking someone to write an entire program for me, but most of the time it's just that I need to know what command to use, or maybe help with the syntax for one command. And in that case, my feeling is that if you know the answer just give it, and if you don't, just wait and maybe someone else will. Don't be the guy who just has to say something even it it is totally unhelpful. Unfortunately, as you note, giving that sort of unhelpful response is a time-honored (I would say dishonored) tradition among certain Linux users, and that is probably one reason why there are so many people (Windows and OS X users) ready to blast into a tirade at the mere mention of Linux. I figure that if you really feel that reading the documentation would actually be helpful, the very least you can do is give some idea what to look for in the documentation, say a particular section or a page number. But I also would not be so bold as to just assume that someone does not know that the documentation exists, or that they haven't looked at it and found it to be terribly obtuse and unhelpful.

Anyway, that said, I am particularly appreciative of your help and comments in this thread. Even if we wind up not going through with this project, I hope they will be useful for someone, and I have learned quite a bit today. :)

Joe Schmoe
Posts: 4277
Joined: Sun Jan 15, 2012 1:11 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Thu Jul 11, 2013 2:19 am

Well, all I will say about that is that is exactly the sort of behavior that drives some people to Windows or OS X,
Heh heh. Guess what command I use to learn just about everything that I have learned about the commands in Mac OS X? Yup, "man"...
And some folks need to stop being fanboys and see the forest behind the trees.

(One of the best lines I've seen on this board lately)

anik
Posts: 15
Joined: Tue Jul 09, 2013 7:43 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Thu Jul 11, 2013 3:37 am

Joe Schmoe wrote:
Well, all I will say about that is that is exactly the sort of behavior that drives some people to Windows or OS X,
Heh heh. Guess what command I use to learn just about everything that I have learned about the commands in Mac OS X? Yup, "man"...
Wait, you mean that there are Mac users that don't stay entirely within the Apple GUI? :shock: Does Apple know about this?! :mrgreen:

anik
Posts: 15
Joined: Tue Jul 09, 2013 7:43 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Thu Jul 11, 2013 4:01 am

To summarize, I think what is being said here is that you could create a batch file as follows (assuming that cifs-utils has been installed and you want to keep one current plus two older backups):

Code: Select all

#!/bin/bash
mount -t cifs //local_ip_address/share_name/backup_directory/ /mnt/ -o username=home/username,password=secret
# Could use some type of check here to make sure connection is established and if not, take some action or exit gracefully
cd /mnt
rm backup2.img
mv backup1.img backup2.img
mv backup0.img backup1.img
# Use either one of the following lines, depending on whether you like cp or dd better...
cp /dev/mmcblk0 /mnt/backup0.img
# ... OR ...
# dd if=/dev/mmcblk0 of=/mnt/backup0.img bs=1M conv=sync,noerror
umount /mnt/
I have not actually tested the above yet because we've still not decided whether we are going forward with this, but I just wanted to try to summarize the information in the above posts into (what should be) a usable batch file. And also, you should probably put a text file or something in the destination directory, to remind you to run fsck should you ever actually need to install one of these backups.

Joe Schmoe
Posts: 4277
Joined: Sun Jan 15, 2012 1:11 pm

Re: Backing up the SD card - what's difference .bin vs. .img

Sun Jul 28, 2013 4:10 pm

BTW, I've never had to install "cifs-utils" (or anything else) to be able to use mount to mount Samba shares (from Windows boxes). So, I'm not sure where you got that from.
And some folks need to stop being fanboys and see the forest behind the trees.

(One of the best lines I've seen on this board lately)

Return to “Beginners”