Bug - Backup Exec 2010 returns "Access denied" if a directory is moved during the backup

It's a bug report.

When we're running a backup of a file using RALUS, if the directory which contains the file is moved (for example, renamed), the backup of this file (and of all the other files inside this dir) will fail with the error "Access is denied to directory ...".

However, we had permission to access this directory during all the backup time. The log error is wrong.

Description (step-by-step)

We have a "Selection List" with one resource:

\\backup.2aliancas.com.br\[ROOT]/var/exports/backups/mydir/*.* /SUBDIR

The directory mydir is a directory (EXT4 backend) in the backup.2aliancas.com.br server (a Linux server with RALUS) with the following structure:

/mydir
   |-> dir1
        |-> file1.txt
        |-> file2.txt

For simplicity, consider that these files are big (like 10G each one). So, it will be easier to reproduce the problem.

Now, let's start the RALUS deamon in debug mode:

$ /opt/VRTSralus/bin/beremote --log-file /tmp/bug.log &
$ ps aux | grep beremote
root     21725  0.1  0.1 222900 14540 pts/0    Sl   13:27   0:00 /opt/VRTSralus/bin/beremote --log-file /tmp/bug.log
$ ls -lh /proc/21725/fd
total 0
lrwx------ 1 root root 64 2015-07-01 13:29 0 -> /dev/pts/0
lrwx------ 1 root root 64 2015-07-01 13:29 1 -> /dev/pts/0
lrwx------ 1 root root 64 2015-07-01 13:28 2 -> /dev/pts/0
l-wx------ 1 root root 64 2015-07-01 13:29 3 -> /tmp/bug.log
lrwx------ 1 root root 64 2015-07-01 13:29 4 -> socket:[18882216]
lrwx------ 1 root root 64 2015-07-01 13:29 5 -> socket:[18882217]

Now, let's start a backup (the used settings are attached).

After some time, we can see that RALUS is backing up the file file1.txt and also two file descriptors are opened (one for the directory dir1, and one for the file file1.txt):

$ ls -lh /proc/21725/fd
total 0
lrwx------ 1 root root 64 2015-07-01 13:29 0 -> /dev/pts/0
lrwx------ 1 root root 64 2015-07-01 13:29 1 -> /dev/pts/0
lrwx------ 1 root root 64 2015-07-01 13:28 2 -> /dev/pts/0
l-wx------ 1 root root 64 2015-07-01 13:29 3 -> /tmp/bug.log
lrwx------ 1 root root 64 2015-07-01 13:29 4 -> socket:[18882216]
lrwx------ 1 root root 64 2015-07-01 13:29 5 -> socket:[18882217]
lrwx------ 1 root root 64 2015-07-01 13:42 6 -> socket:[18886347]
lr-x------ 1 root root 64 2015-07-01 13:42 7 -> /var/exports/backups/mydir/dir1
lrwx------ 1 root root 64 2015-07-01 13:42 8 -> socket:[18886422]
lr-x------ 1 root root 64 2015-07-01 13:42 9 -> /var/exports/backups/mydir/dir1/file1.txt

Now, let's rename dir1 (same inode and file descriptor, different name) and create a new dir1 directory (a new inode):

$ mv /var/exports/backups/mydir/dir1 /var/exports/backups/mydir/dir2
$ mkdir /var/exports/backups/mydir/dir1

Now, let's check the opened file descriptors:

$ ls -lh /proc/21725/fd
total 0
lrwx------ 1 root root 64 2015-07-01 13:29 0 -> /dev/pts/0
lrwx------ 1 root root 64 2015-07-01 13:29 1 -> /dev/pts/0
lrwx------ 1 root root 64 2015-07-01 13:28 2 -> /dev/pts/0
l-wx------ 1 root root 64 2015-07-01 13:29 3 -> /tmp/bug.log
lrwx------ 1 root root 64 2015-07-01 13:29 4 -> socket:[18882216]
lrwx------ 1 root root 64 2015-07-01 13:29 5 -> socket:[18882217]
lrwx------ 1 root root 64 2015-07-01 13:42 6 -> socket:[18886347]
lr-x------ 1 root root 64 2015-07-01 13:42 7 -> /var/exports/backups/mydir/dir2
lrwx------ 1 root root 64 2015-07-01 13:42 8 -> socket:[18886422]
lr-x------ 1 root root 64 2015-07-01 13:42 9 -> /var/exports/backups/mydir/dir2/file1.txt

PS: This is the expected behavior of Linux at this point.

After some time, the backup of file1.txt ends, and RALUS logs some errors. After, RALUS tries to get the next files to backup and logs another error.

When the backup ends, Backup Exec logs "Access denied to directory /var/exports/backups/mydir/dir1.", which is a unuseful message. There is not access denied (both the old dir1 (now dir2) and the new dir1 are accessible all the time).

The RALUS log file is attached at this bug report also.

Expected behavior

There's no well defined expected behavior for this.

However, good solutions could be:

• Keep copying the others files in the directory dir1;
  • It is, at the end of the backup, both files would be backed up at mydir/dir1/file1.txt and mydir/dir1/file2.txt;
  • This is what cp and rsync would do;
  • This is possible because the file descriptor, the directory stream, the inode number and all the other attributes of the directory are still the same after the rename;
• After realise that dir1 was renamed, stop copying the other files (only mydir/dir1/file1.txt would be backed up) inside dir1. A warning "Directory renamed: Skipping directory /var/exports/backups/mydir/dir1" could be logged instead of "Access denied".