The first example creates an archive "archive.1.tar" of /home/user. The archive is written to the current directory where the command is run. You could use "-C <directory>" option to explicitly indicate where the working directory should be.
In the second command, instead of creating a physical file on the same computer, the archive is sent out stdout, piped to the input of the tar command running on a remote computer. The ssh command creates a secure connection to the host hpmedia. So the archive is streamed over the network and extracted to the other machine. An actual file is never created, just sent over the network.
Using the "-g logsnap" argument to the tar command on the local computer; the first time you run this command the ~/logs/ directory is fully archived. Now imagine that a file or files are edited in ~/logs/. The next time this command is run, an incremental archive is created instead and only the modified & new files are sent. Using ssh, this could be done securely over the internet.
I used the -v option in the tar command extracting the files, so I could see which files where being created on the remote computer. The "touch logs/freenode.log" command updated the timestamp. Then I reran the command to demonstrate that indeed, a file newer than the timestamp was copied to the remote machine. This is doing what you asked about in your first post, copying files from one computer to the other and later doing the same only for files that have changed.
You can tweak this command, using -C <dir>, as the examples in the tar info manual do to set where the command is executed from. So `-C /home' will start tar from the /home directory. You can have use -C on the tar command on the right hand side so that the files are extracted where you want them to be.
Some ssh details
Please note, that I am using public key authentication for ssh access. I use a passphrase, but I used ssh-agent so that I wasn't prompted for a password when I ran the command. The passphrase is requested on the client side, to unlock the private key. If you read the comments above the "UsePam Yes" line in the /etc/ssh/sshd_config file, you should have no problem configuring public key authentication. The paragraph tells you which options to disable and which to disable.
You also need to add the contents of your clients ~/.ssh/id_rsa.pub to the servers ~/.ssh/authorized_keys file.
Another tar example
In the example using tar to copy modified files, please realize that I am not creating a backup. I am using tar to transport the files that would be backed up if I were to create a backup. This next example does both at once!
tar -g policies.ts -cf - policies/ | tee /mnt/maxtor/policies-12-19-08.tar.gz | ssh hpmedia 'tar -xvp
The "everything is a file" philosophy of Unix sure comes in handy, doesnt' it. The `tee' command is like a tap. Inserting it where you have a pipe, the standard input is saved to a file (policies-12-19-08.tar.gz), and also sent out stdout. The /mnt/maxtor/ directory is a mounted Samba share on a Maxtor Central Axis networked drive.
If you were to use this in a script, the filename used will need to be changed each time it is run, to prevent over-writing the last backup. Using something like "$(date)" in the filename will make the filename unique.
Back to more ssh details
If the incremental backup/transfers are for system directories, you will need to allow root ssh access. This is another reason to only use public key authentication. Brute force script kiddie attacks won't work because you simply don't use the authentication they are trying. You can't try a key if there isn't a keyhole!