Hi,
Having a problem with my server. I have a schedule set to perform a backup (Restore Point) every 12 hours, however it always results in an error - as seen in the webui, “Warning - last restore point from x minutes ago failed” or whatever it says (can’t remember exactly and I’ve since refreshed, losing that text).
In the mineos.log, all I see is this, and looking back it seems to have this non-descriptive error every time a scheduled backup is performed:
{“level”:“info”,“message”:"[Reign] received request “backup”",“timestamp”:“2016-09-06T14:00:00.513Z”}
{“command”:“backup”,“source”:“0 */12 * * *”,“msg”:"",“enabled”:true,“success”:false,“err”:1,“time_resolved”:1473170400542,“level”:“error”,“message”:"[Reign] command “backup” errored out:",“timestamp”:“2016-09-06T14:00:00.542Z”}
When I create a Restore Point manually in the webui, I get no error. When I run rdiff-backup manually in ssh shell - as the same “minecraft” user that I login to MineOS with - I also never get an error.
The only unique thing about my install is that I have /var/games/minecraft soft-linked to /home/minecraft/ - the owner and permissions of everything in /home/minecraft/ is correctly set.
Any pointers on how I can further diagnose this? Thanks in advance for any help.
Let’s start with recreating the scheduled backup. Here is the documentation for the cron syntax expected (also linked in the webui).
Seconds: 0-59
Minutes: 0-59
Hours: 0-23
Day of Month: 1-31
Months: 0-11
Day of Week: 0-6
Most notably, there are six different cron arguments expected; mind you, this might not be what’s causing the fault, but since it is expecting six vs. five, let’s tackle this one first. According to wanting to do it every 12 hours,
0 0 */12 * * *
Give that a runthrough (and delete the existing backup crontab) and see how it goes.
Strange, crontab generator only gave me five numbers.
Ok, I’ve deleted the old one and created a new backup schedule with 0 0 */1 * * * - I’ll let you now how it goes.
Not sure how I glossed over this the first time, but I’m more than willing to bet this is the issue at hand. I’m going to try to reproduce this issue. Have you considered a hard link instead, too?
I don’t know a great deal about Linux but from what I understand, hard-linking directories is a no-no, isn’t it?
There is the bind-mount option though, I am familiar with that from the Android world. If I have an error again, I’ll give a bind-mount a go instead.
I can definitely understand why hardlinks might be frowned-upon, though I have found them to be very useful for a number of reasons where bind-mounting wasn’t ideal.
Hardlinking makes the link to the destination as real as the destination itself, which means that if you were to delete the hardlink, you’re taking the destination itself. Understandably, this could be scary–very scary–if you hardlinked it to /home/minecraft.
Realistically, I think that whether you symlink, hardlink, or bind-mount, you probably should opt to have it go inside /home/minecraft/someotherdir, because backups should be organizationally isolated, and lots of stuff shows up in /home/minecraft that doesn’t belong in the same container as /var/games/minecraft.
That said, one of the things that’s good about hardlinking is that it doesn’t do cross-mount (it’s the same mount). Some apps, though not sure about rdiff-backup–don’t like cross-mounting, or require flags that tell it to cross mounts. If rdiff-backup dislikes cross-mounting, though, the backups you made manually probably would have failed too.
Ok I had the error again. I can’t do a hard-link because /home is mounted too a different device than /[var] is. So I moved the mineos folders into /home/minecraft/mineos/ and am trying a bind-mount from /var/games/minecraft to that folder.
Finger’s crossed.
Ok, using a bind mount seems to have solved it. Schedule was set to backup every hour, and there have been no errors the past day.
Thanks!
1 Like