Re: [Dump-users] Incremental backup features of dump

[Antonios C. <an...@it...>]

Brent Busby wrote:
> 1)  Will dump track file deletions between incremental backups?

Yes.
(And GNU tar can also do this, though I found its options much harder to
figure out.)
 
> 2)  If a file is copied onto a partition from another machine, and the
>    file has a datestamp that's older than the latest dump recorded in
>    /etc/dumpdates for that volume, will the next incremental catch the new
>    file, on the premise that it didn't exist there before?

It will catch it, but not on the premise that it didn't exist before; on
the premise that its ctime is later than the dump time.

A file has three times: mtime (last modification), atime (last read),
and ctime (last inode modification).  If you make any change to the
inode, such as change permissions, modify atime or mtime (e.g. with
touch), or change owner, then ctime gets modified. There is no way to
override this, and there is no way to alter ctime.

So, when you copy a file (e.g. with cp) with the option to preserve its
attributes, copying goes like this:
  - First cp creates the destination file and copies the file contents
    there.
  - While cp does this, the kernel automatically sets the file's mtime
    to the current time.
  - When cp finishes copying the data, it asks the kernel to set the
    file's mtime to the source file's mtime.
  - When the kernel does this, it will automatically set ctime to the
    current time.

Because that's how the kernel works, the same will happen whichever
utility you use for copying, including restore.

Dump looks at mtime and ctime and uses the max of these two in order to
decide if the file has changed or not.