headers
Lasse Kliemann | 22 Jun 2007 15:25

missing files from incremental backups


Experiment:

One process repeatedly generates a random filename and then touches, removes 
or writes a files by this name (which can result in an existing file to be 
modified). In other words: we have a very simple simulation of an active 
filesystem.

While this goes on, incremental backups of levels 0 to 9 are done with the 
following command:

star -c -xdev -sparse -acl -link-dirs level="${level?}" -wtardumps \
  f=level-"${level?}".star -C "${mount?}" .

Then, the generating process is stopped and one final backup of level 10 is 
made. Nothing modifies the filesystem during this.

A copy of the backed-up filesystem is made using `cp -a' (from now on called 
`the copy'), then the filesystem is deleted and restored with the command 
from the manual page:

cd /filestem-mount-point 
star -xpU -restore f=...

applied to files level-0.star up to level-10.star. During the restore, there 
are several warnings like this one:

star: WARNING: No new inode number for /alive/file_391

Then the copy is compared to the restored filesystem.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joerg Schilling | 25 Jun 2007 19:03
Picon
Favicon

Re: missing files from incremental backups

Lasse Kliemann <lasse-list-star-users <at> mail.plastictree.net> wrote:

>
> Experiment:
>
> One process repeatedly generates a random filename and then touches, removes 
> or writes a files by this name (which can result in an existing file to be 
> modified). In other words: we have a very simple simulation of an active 
> filesystem.

This is a case, that cannot be handled correctly without using a fs snapshot
for the dump.

> While this goes on, incremental backups of levels 0 to 9 are done with the 
> following command:
>
> star -c -xdev -sparse -acl -link-dirs level="${level?}" -wtardumps \
>   f=level-"${level?}".star -C "${mount?}" .
>
> Then, the generating process is stopped and one final backup of level 10 is 
> made. Nothing modifies the filesystem during this.

If files in a directory are removed/renamed or created after the directory 
namelist has been read using readdir() and before star archives them, many 
things may happen.

As star uses fetchdir(), all files that miss after the readdir has been done
will create a warning. If the file system may reuse the inode numbers for 
other file names that did exist before with a different inode number, anything
may happen. Star is not better than the OS you run it on. If you like to backup
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lasse Kliemann | 26 Jun 2007 11:45

Re: missing files from incremental backups

* Joerg Schilling writes:
> Lasse Kliemann <lasse-list-star-users <at> mail.plastictree.net> wrote:
> 
> >
> > Experiment:
> >
> > One process repeatedly generates a random filename and then touches, removes 
> > or writes a files by this name (which can result in an existing file to be 
> > modified). In other words: we have a very simple simulation of an active 
> > filesystem.
> 
> This is a case, that cannot be handled correctly without using a fs snapshot
> for the dump.

[...]
> If files in a directory are removed/renamed or created after the directory 
> namelist has been read using readdir() and before star archives them, many 
> things may happen.
> 
> As star uses fetchdir(), all files that miss after the readdir has been done
> will create a warning. If the file system may reuse the inode numbers for 
> other file names that did exist before with a different inode number, anything
> may happen. Star is not better than the OS you run it on. If you like to backup
> a life filesystem use snapshots.

Obviously, these are aspects I had not considered. Out of curiosity, I did 
some more runs today using the dumpdate feature (as described in the manpage, 
but without the filesystem snapshot). Comparing the copy with the restored 
filesystem revealed no missing files this time (which might not say much, 
since I only did a few runs). However, files still differed in contents.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lasse Kliemann | 28 Jun 2007 22:40

empty archives

star can create empty archives, but does not recognize them afterwards.  

For example:

% find . -name foo

So, there is no file `foo' here.

% star c f=t.tar -find . -name foo
star: 1 blocks + 0 bytes (total of 10240 bytes = 10.00k).

% star t f=t.tar
star: Unknown archive type (neither tar, nor bar/cpio).

% gtar tf t.tar 

% echo $?
0

% uname -a
Linux 2.6.19.7-snyder #5 Sun May 13 18:13:50 CEST 2007 i686 i686 i386 GNU/Linux

% star -version
star: star 1.5a82 (i686-pc-linux-gnu)

This is especially problematic with incremental backups when no files have 
changed since the last backup. Say, one does a level n backup, and after 
this, no files change on the backed-up filesystem. Then one does a level n+1 
backup, and after this a level n+2 backup. The level n+1 backup is an empty 
archive and hence cannot be restored (see above: "star: Unknown archive type
(Continue reading)

Permalink | Reply | 0 comments |
headers
The Loeki | 29 Jun 2007 14:28
Picon

E13 - Permission Denied as root or whoever

Hi all!
 
We're using Solaris 10u3 11/06 on an UltraSPARC
It has a DDS4 tape device attached to it, which I want to publish to other servers as well.
 
I figured I'd use Schily's rmt for access to it's tape device.
After some hassle setting up the server, I continued to receive
/opt/csw/bin/sdd: Permission denied. Remote status(open): 13 'Permission denied'.
 
So I figured I'd try on a SSH terminal to figure this stuff out.
As root, consider the following output:
 
# /usr/sbin/rmt
O/dev/rmt/0hn
S
A3
 
<<SNIP>>
Seems regular, right?
Now it's star's rmt's turn:
 
# /opt/csw/sbin/rmt
O/dev/rmt/0hn
S
E13
Permission denied

!?
Does anybody have any idea why exactly this is? Remember, this is not as user or with interruption from rsh or rlogin or whatever...
 
I'd be happy with any ideas :-)
 
_______________________________________________
Star-users mailing list
Star-users <at> lists.berlios.de
https://lists.berlios.de/mailman/listinfo/star-users
Permalink | Reply | 0 comments |

Gmane