Admin page unavailable after cancelled backup job & hard reboot, shares are working

---

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.

OMG. That is absolutely possible. rsync backup jobs on the RN214 always were a mystery to me, however still being the only choice to have a one-click incremental nobrainer backup to an attached USB3 device excluding btrfs snapshots and a couple of other unnecessary directories. Once I got aware of the /media/media problem, I wanted to avoid 4TB of redundant data being copied only to be deleted once the job was finished. Hence I canceled the job and did not really care about the HDD access  LED in the NAS. I then probably have ejected the USB device (don't really remember if I did) or it could be that at that point the admin page was already unresponsive.

Since I was stupid enough not to enable SSH and the power button shutdown did not work, I had to pull the plug. Later I learned about RAIDar, which I could have tried to force a shutdown as well.

After the forced restart, the admin GUI just showed the progress bar similar to https://kb.netgear.com/26883/ReadyNAS-OS-6-Admin-Page-is-offline, no way around that. I resorted to the OS reinstall boot menu option after which I could log onto the admin GUI successfully. Then I saw the "Volume: System volume root's usage is 99%. This condition should not occur under normal conditions. Contact technical support." log message but sure enough, I don't have any technical support contract.

So the master plan was to enable SSH shell access for admin, which failed (blocked GUI again and all other kinds of weird behaviour). After a couple of OS reinstalls, suddently a "firmware image unpack failure" (or likewise) was displayed on the LCD panel and the admin GUI came up completely non-localized, with just the message tokens/placeholders instead of the real messages. Still no SSH access.

That was the moment when I called it a day and performed a complete factory default reset, knowing that I had at least backed up all the data (without the snapshots unfortunately, since the NTFS partition on the external USB drive does not support them). Currently, the device is resyncing its data (at ~10%).

---

Sandshark wrote:

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.

That was the plan. But it seems that my iterations and an OS partition filled up to the brim was not allowing this configuration change. Lesson learned. Enabling SSH was the veryfirst thing I did after the RN214 came up in it's pristine state.

---

Sandshark wrote:

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 should 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.

---

Usually I'm aware of those rsync subtleties but that's what happens, if you're copying files while working on other stuff in parallel...

The big question is now: If I run an rsync backup job in the future and find out that things are going haywire: What is the recommended way of cancelling them in a safe way so that this disaster can't happen again? Does it suffice to wait for the job shown as "Cancelled"? Is there a logfile to have a look at?

That was quite a miserable day to say the least. Nevertheless many thanks for your explanations, I learned a lot about rsync again.

---

 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...