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.
Restore using an rsync backup job will take a lot longer than just using a standard internal to intenal one, which seems to be little more than a cp -a.
Sandshark wrote:Restore using an rsync backup job will take a lot longer than just using a standard internal to intenal one, which seems to be little more than a cp -a.
OK. I have just started a good plain old local copy job from the connected external USB box to a NAS share and forego with any fancy checksums *). Let's hope the data arrives intact and the whole process is not going to take an eternity.
Thanks again!
*) ... for now. I can still rsync -c later, use TotalCommander from the Windows PC, Meld, or mess with hashes later.
VolkerB wrote: I can still rsync -c laterThe rsync checksums are only needed when you doing an incremental restore, but think you might have corrupted files already on the target. If the file
- exists on the target
- has the same size
- has the same file date
then rsync compares the two checksums and updates the files if the two checksums differ. Checksums are used to instead of direct comparisons to preserve bandwidth on the network link (which doesn't apply in your case anyway).
If your goal is to simply verify the folder contents after the backup, I suggest just using
diff -qr /path0 /path1
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
