You can't use tar this way. Or you need to patch it.
If you don't give a file (you don't use the -f option), tar will use the standard output by default, i.e. the terminal and eventually fail because it will refuse to write compressed data on the terminal.
So, you have to call tar the proper way : tar -zcvf prog.tag.gz /home/jerry/prog.
It depends on the amount of fudging you're willing to do.
Let's use format 1 for a moment. It's a list only of the directories in the tarball.
The fields relevant to each entry in the list tarball are: mtime(seconds+nsecs), device, inode.
In later incremental passes, if the device/inode fields no longer match, or if the mtime has moved backwards, ALL the files in the directory will be added to the incremental tarball. If the device/inode match, and mtime is the same or greater, it will pick up all new files greater than or equal to the mtime (The equal-to part matters for filesystems with low mtime resolution, otherwise files might be skipped).
Format 2 extended this via the Dumpdir format, which complicates it,
mostly adding cases where files aren't backed up as they came with an older mtime.
So, given a tarball, is it possible to recreate a snapshot file? Yes, but it's messy, and you'll probably miss some files. There is --no-check-device which skips the device check, but the directory inodes are the big risk.
Best Answer
An image is a raw (literal, byte for byte) copy of a filesystem. Because this includes all the fs meta-data, you can mount it the same way you would mount a physical device with the exact same byte for byte data on it.
A tar file (aka. a 'tarchive') is an archival format that is filesystem agnostic -- although it includes information such as permissions, ownership, and maintains directory structure, it does not depend further upon the source filesystem. This means tarchives are portable from one type of filesystem to another; anywhere you have a
tarutility, you should be able to use a tarfile regardless of origin.A tarchive is not a literal byte for byte copy of a region of storage. It's a set of files structured by tar, and hence, unlike an image, its contents can be analyzed and manipulated externally (by the
tarutility itself). This also means it does depend on some existing filesystem in order to be unpacked and used.A tarchive can contain the contents of an entire filesystem, but this is not the same as containing the actual filesystem, as an image does. In order to reproduce the original fs, you would have to create an fs partition of the same type (n.b., which the tarchive contains no indication of) and unpack into it. Conversely, if you want to "unpack" an image into a subdirectory of an existing filesystem, you must mount it and copy out manually (although there may be tools to aid in this).
So, the two methodologies best suit slightly different purposes. With regard to back-ups, tar is the better choice for a number of reasons:
/proc,/dev).