[rsnapshot-discuss] lockfile problem and corrupted file problem

[Anna Hegedus]

Hello everyone,

This is really my first foray into backing up files with rsnapshot. I
inherited this system from a previous system administrator and
basically, he left in a hurry! I'm having two problems right now with
rsnapshot from what I can see...

The first problem - The daily backups are not running right now.
Whenever they are initiated by cron, the backup appears to start, then
stalls and dies with the following message in /var/log/rsnapshot:

"/usr/bin/rsnapshot daily: ERROR: Lockfile /var/run/rsnapshot.pid
exists, can not continue!"

Would it be all right for me to just remove this lockfile and continue
the backups as normal? Or is there something else I can do?

Problem number two is that the backups are becoming corrupted every once
in a while (Either by the issue above or something else that can't be
determined). The backups are not able to be removed from the directory
(probably because of broken links) with rm -f. I'm getting a bunch of
messages saying "access denied" when I try to take these out. I'm
guessing I need to take this drive, unmount it, then run a reiserfsck
over it, but I just wanted to double-check if anyone else has had this
same problem before I embark on a 9 day trek. Also, when these backups
become corrupt, I have been mv'ing them as follows:

mv daily.0 corrupted.0
mkdir daily.0

when I try to do this:

cp -r daily.1 daily.0

It won't let me. It just sits there for hours.

ANY help you can provide would be excellent. As I am used to doing
backups on an old S390 mainframe, this is a bit new for me ;)

Thanks again!
Sincerely,
Anna

[Helmut Hullen]

Hallo, Anna,

Post by Anna Hegedus
The first problem - The daily backups are not running right now.
Whenever they are initiated by cron, the backup appears to start,
then stalls and dies with the following message in
"/usr/bin/rsnapshot daily: ERROR: Lockfile /var/run/rsnapshot.pid
exists, can not continue!"
Would it be all right for me to just remove this lockfile and
continue the backups as normal? Or is there something else I can do?

When is "rsnapshot hourly" started, when is it finished?
When is "rsnapshot daily" started?

It's a good choice to start "monthly" first (on a day), then "weekly",
then "daily" and at last "hourly".

Viele Gruesse!
Helmut

[David Cantrell]

Post by Helmut Hullen
Hallo, Anna,

Post by Anna Hegedus
The first problem - The daily backups are not running right now.
Whenever they are initiated by cron, the backup appears to start,
then stalls and dies with the following message in
"/usr/bin/rsnapshot daily: ERROR: Lockfile /var/run/rsnapshot.pid
exists, can not continue!"
Would it be all right for me to just remove this lockfile and
continue the backups as normal? Or is there something else I can do?

When is "rsnapshot hourly" started, when is it finished?
When is "rsnapshot daily" started?

Assuming that Anna is running an "hourly" backup as well, of course.

Post by Helmut Hullen
It's a good choice to start "monthly" first (on a day), then "weekly",
then "daily" and at last "hourly".

Indeed. That's because only the first "interval"* to appear in your
config file actually takes a backup, and consequently, only that one
will take a long time. The others just involve moving directories
around which is very quick. The general solution is to run your backups
in order from least often to most often with at least a few minutes
between them, and to turn on "lazy deletes"**. My crontab, for example,
looks like this:

00 00 * * * /usr/local/bin/rsnapshot daily
00 22 * * 6 /usr/local/bin/rsnapshot weekly
00 20 1 * * /usr/local/bin/rsnapshot monthly

So "monthly" backups happen at 8pm, followed by weeklies at 10pm and
finally dailies at midnight.

Now, to solve Anna's specific problem - cat the offending rsnapshot.pid
file to find the process ID of the rsnapshot instance that put it there.
Then use ps to see if that process still exists. If it doesn't, you can
safely delete the file. However, you should also check your log file to
see if you can find any evidence for why it got left there.

The most recent version of rsnapshot (1.3.0) does this for you
automagically. The current version in CVS (and the eventual 1.3.1
release) also have the option to *not* automagically clean up and
carry on. You are very strongly advised to upgrade to 1.3.0 if you're
not using it already because as well as lots of nifty features it has
work-arounds for changes in recent versions of the GNU tools.

* and remember that "interval" is renamed to be "retain" in the CVS
version and in the next release
** lazy deletes are supported since 1.2.9 IIRC

[David Cantrell]

Post by Anna Hegedus
Problem number two is that the backups are becoming corrupted every once
in a while (Either by the issue above or something else that can't be
determined).

Corrupted how? It's *extremely* unlikely that your lockfile problem is
causing this corruption, although the two problems could well have a
common root cause.

Post by Anna Hegedus
The backups are not able to be removed from the directory
(probably because of broken links) with rm -f. I'm getting a bunch of
messages saying "access denied" when I try to take these out.

If you're not running rsnapshot and rm as root, then that's almost
certainly the reason. Otherwise, it *is* possible to create directories
which don't have any of the x bits set, but again, running rm as root
will override that.

Post by Anna Hegedus
guessing I need to take this drive, unmount it, then run a reiserfsck
over it

It's possible. While you've got it unmounted, also try the reiserfs
equivalent of badblocks -n.

Post by Anna Hegedus
but I just wanted to double-check if anyone else has had this
same problem before I embark on a 9 day trek. Also, when these backups
mv daily.0 corrupted.0
mkdir daily.0
cp -r daily.1 daily.0
It won't let me. It just sits there for hours.

It might sit there for hours simply because the cp is taking a VERY long
time - depends how big your backups are, I suppose. Bear in mind that
cp -r will *not* create the necessary hard links or preserve ownership
and mode. If you're using GNU cp (and your mention of reiser_fsck makes
me think you probably are) then you need to use cp -al. If you want to
confirm that it's actually doing something add -v to the mix.

Of course, if you're trying to specifically create a new directory
*without* hard links to old backups, then miss out the -l. Still use -a
though, as that is a shortcut for -dpr.

Post by Anna Hegedus
ANY help you can provide would be excellent. As I am used to doing
backups on an old S390 mainframe, this is a bit new for me ;)

Yes, it is a bit different :-)