NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Admin page unavailable after cancelled backup job & hard reboot, shares are working
Hopefully someone can help me get out of this deadlock. I recently added a rsync backup job to sync the local /media share with an USB drive that was connected via the rear USB socket of the RN...
Did you at any point disconnect or power down the USB drive before the backup job said it was done? I ask because I suspect that it continued after that. But once the USB drive wasn't connected, it began to copy files to the mount point in the OS partion instead of the USB drive that should have been mounted there. That'll fill the OS partition in a hurry.
The message you are seeing is the location where the OS crashed, undoubtedly due to the too-full OS partition. If you are now able to enable SSH after the OS re-install, you need to go in and clear out any files that were copied to the mount point directory.
The fact that your files were copied to media/media is the way the rsync backup jobs are designed. I disagree that's the way it shoud be, but it is. The work-around is that you need to go back into the backup job configuration after it's created and put a single forward slash "/" as the source path.
Sandshark wrote:Did you at any point disconnect or power down the USB drive before the backup job said it was done? I ask because I suspect that it continued after that. But once the USB drive wasn't connected, it began to copy files to the mount point in the OS partion instead of the USB drive that should have been mounted there. That'll fill the OS partition in a hurry.
OK, come to think of it and to avoid trouble in the future... Please apologize, if the follwing is a potentially stupid question:
Assume, I want to backup a couple shares to an external USB drive connected to the ReadyNAS. I want to use rsync, because that allows hassle free incremental updates. So I connect the drive, enable RSYNC R/W access for that drive in the admin page share section like this:
Now assume, I want to create a backup job for all home shares like this:
As destination, I point the NAS to the remote rsync server on 127.0.0.1 (which is essentially the local machine accessing the USB drive via rsync):
I exclude the /admin/snapshot directory, because this will confuse the NTFS filesystem and set the --delete option to remove remote files that don't exist locally anymore:
So far, so good.
This backup seems to be bound to the share HDS5C3020ALA632 for the destination. Now assume, that drive is not connected but I accidentially hit the backup button on the NAS. I hope, in this case it is NOT writing to the OS partition but rather failing the operation in the first place as any sane person (and all the Linux OSes I have worked with) would do.
Am I right? Thanks again for your patience. I'm getting a bit paranoid after three sleepless nights. :smileywink:
P.S.: I hope the screenshots show up in my post. I can see them while editing but after posting, there's just the yellow triangle...
I've not tried it, but I think the answer may be that it will write to the OS partition in that case. I know rsync can't tell the difference when a directory that's intended as a mount point actually has something mounted to it or doesn't, but does somehting in the NAS unique software check first?
The screen grabs are there. A moderator has to approve them, but that's obviously already taken place.
I think this is worth some time with my "sandbox" NAS, so I'll give it a try some time this weekend if I have the time. You may have more fully explained why so many have issues with a too full OS partition. We've seen instances that were clearly related to an unmounted USB drive, but I never thought about the backup button being a trigger.
Or, if you want to try it, do so with a share that has very little in it, so the OS partition won't fill and you can still get in with SSH and check the content of the mount point with nothing mounted and delete anything that is there.
Sandshark wrote:[external media absent, so rsync] will write to the OS partition in that case. I know rsync can't tell the difference when a directory that's intended as a mount point actually has something mounted to it or doesn't, but does somehting in the NAS unique software check first?
I vaguely remember that I had a couple sanity checks in my backup.sh on the Linux box and it was failing early if the share was not mounted. There was an entry similar to
//rn214/media /media/rn214/media cifs noauto,users,credentials=/home/admin/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0
//rn214/admin /media/rn214/admin cifs noauto,users,credentials=/home/anja/.smbcredentials,iocharset=utf8,uid=1000,gid=1000,file_mode=0770,dir_mode=0770 0 0in fstab and I was checking the backup target directory with
if [ ! -d "$TARGET" ]; then echo "# Error: Target directory '$TARGET' does not exist." 2>&1 | tee -a "$LOG" exit -1 fi
which seemed to work.
Sandshark wrote:You may have more fully explained why so many have issues with a too full OS partition. We've seen instances that were clearly related to an unmounted USB drive, but I never thought about the backup button being a trigger.
IMHO that's the purpose of this button in the first place: Allow a hasslefree nobrainer backup.
- Connect external drive.
- Press button.
- Wait until process is finished/email received.
- Eject drive, disconnect.
- Enjoy life.
If you're in constant danger of exploding your OS root volume doing so and having to run a factory reset if SSH is not available, that would severely spoil my fun to say the least. Losing all snapshots and spending more than one full day to restore 5TB of data is nothing that I want happening to me anytime soon.
On a sidenote: I eventually came up with a quite elegant (OK, translation: not totally clumsy) way of backing up the entire data volume of the NAS with one single backup job. So assume a big disk is attached as ST8000VN0022 via USB, rsync enabled:
Let's then declare volume:data as the rsync source and add the slash "/" to the path, so there is no useless directory "data" created at the target:
The rsync target is of course the external HDD on localhost:
I had to enable the "Multiple Files Systems" option (otherwise the shares underneath "data" weren't included in the backup) and add "home/admin/snapshot" etc. to the rsync ignore list, because I had btrfs and smart snapshots enabled for user's homes:
My dry test on a blank HDD worked well, all directories&files equal. So the big question is: Am I missing something totally obvious here or is this a viable way to backup the contents of a ReadyNAS to an external disk of at least equal size?
Sandshark wrote:Or, if you want to try it, do so with a share that has very little in it, so the OS partition won't fill and you can still get in with SSH and check the content of the mount point with nothing mounted and delete anything that is there.
*LOL* Thanks, but no thanks. I really learned my lesson these days, don't have the guts for further experimentation. If this NAS misbehaves to a similar extent again, I'll store my data on punchcards, trust me.
Since I don't actually back up to USB (I have backup NAS), I can't be 100% sure, but you appear to have found all the "secrets" for accomplishing a full volume backup.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
