Extraction puts every member along its path from the chosen directory and silently replaces files with the same names.
The -x option extracts the archive into the current directory; -C picks another one. A file's place is that directory plus the member path: with -C restore, app/config/app.conf becomes restore/app/config/app.conf. The -C directory must already exist, or tar refuses with Cannot open: No such file or directory.
tar replaces a file of the same name without asking. So you first unpack the copy into a separate staging directory, check it, and only then swap it in for the working one. Unpacking straight into live would also overwrite whatever in the working copy is newer than the archive.
The unpacked files belong to whoever unpacks them: for student that is student, even if the archive records root. Only root restores the owners stored in the archive. tar takes the modes from the archive, but without -p it may trim them: rw-rw-rw- becomes rw-rw-r--. With -p the modes are exactly as archived.
The archive in /srv sits on the same disk as the application. Such a backup copy saves you from a broken file, not from losing the disk: for that case the copy lives on another medium, a disk or a machine.
The archive holds the member app/config/app.conf. Where does the file end up after this command?
tar -xpf app.tar -C restore-
tar does not remember where the file was archived from: the
-Cdirectory and the member path set the place. -
-C restorechanges the extraction directory, and the whole member path,app/config/included, is appended to it. -
The member path starts with
app/: that directory appears insiderestore.
The file's place is the -C directory plus the member path. Before unpacking you see the path in tar -tf app.tar, afterwards in ls -R restore.
Key points
-
A file lands in the
-Cdirectory along its archived path, and tar silently replaces a file with the same name. -
Whoever unpacks becomes the owner of the unpacked files;
-pcarries the modes over exactly as archived.