Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[RicRoller]

Using a DNS-320, current firmware 2.02 with 2x 2TB Seagate ST2000DL003 in RAID1

Trying to use remote backup (Rsync) to take a backup copy of files on a company Linux server onto the NAS for off-site storage. NAS and Linux server (Fedora 16) on same LAN (100base-T). There's about 1.5TB of data to be backed up altogether...


1. Got Rsync daemon running on Linux box and a suitable rsyncd.conf file that gives me read access to the folders I want to back up. I have created several "modules" in that file so I can back up each folder tree separately.

2. I can create the manual backup job on the NAS. I have the following observations as I create the job:

(a) I choose the kind of backup job as "NAS to Linux" and "Remote to Local"

(b) I enter the job's name and the folder on the NAS to store the backup.

(c) I enter the Linux server's IP address and the user name/password to use. I don't enable incremental backup support as I'm just after a complete snapshot of what is on the Linux server...

But when I click "Next" there can be a very lengthy "hang" - the status may show as "Testing". This hang time seems to be dependent upon the number of files/folders in the folder tree in the Linux server; in an extreme case with one of the larger folder trees it exceeded the login inactivity timeout on the NAS and it logged me off before I could complete the wizard!! I lengthened the inactivity period to 15 minutes...

(d) I competed the wizard, with the job as "manual" and did not choose to launch it immediately.

(e) Upon clicking the "Backup now" icon in the job's line, the job started; a percentage showed, then after a few minutes it showed as "Finished" But no files were (yet) visible in the NAS!!

However, I could see by refreshing the statistics on disk usage, and by looking at Ethernet activity lights on the switch and the hard disk activity lights on the NAS, I could plainly see that the job had definitely _not_ finished!!

So I left it running in the belief tta the files were being downloaded into a temporary hidden folder and would "magically appear" when the job really did complete...

However, a couple of hours later, it terminated abnormally:
i. There was nothing in the NAS logs or job status to show that anything had failed
ii. The rsyncd.log file on the Linux server showed a "connection reset by peer" error at the time of the failure
iii. About 100GB of disk space had been consumed on the NAS; none of this was visible in any user accessible folders, nor did there seem to be any way to flush it other than reformatting the disks!!


I am trying again - splitting the backup into smaller jobs of 50GB or less, but wonder if:

(a) Is there any known issue with the remote backup - such as limit on backup size or number of files/folders that can be handled by one backup job?
(b) If the backup does fail - is there a way to flush the hidden files - or will they automatically be flushed the next time I run a backup job?


Thanks,
Richard

[RicRoller]

A follow-up to the original posting:

(a) Backing up a smaller set of folders was "successful"; it completed with no errors reported in the rsyncd.log on the Linux server.
(b) But the files transferred are only partially accessible

i. Statistics on hard disk usage in the NAS show that the expected space is occupied
ii. However, if the root folder of the tree that was copied is set up as a CIFS share and mapped as a network drive by a Windows PC or mounted by the Linux PC, none of the transferred files/folders can be seen!!
iii. If using the "web file server" application in the NAS itself, the transferred files/folders _can_ be seen and at first glance appear to be accessible (I could download onto the Windows PC).


So, with care, the remote backup  (Linux to NAS) can be made to work, however there is an issue in the NAS (Samba/CIFS server) in that the transferred files cannot be seen in a shared folder.

BTW  I have tried:
i. Deleting and re-creating the network share
ii. Rebooting the NAS


Regards,
Richard