Looking for NAS Hardware Recommendations

Mon Jul 11 07:13:28 MST 2011

rsync will preserve ownership if you set the option to do so (I don't recall the exact flag offhand).
I actually prefer rsync over the Samba mount because cifs doesn't understand POSIX permissions.

If you root the box you can certainly do the rsync over ssh, but on a local net native(uncompressed) rsync protocol is *immensely* faster because the little ARM chip in the NAS can't handle the ssh encrypt/decrypt very fast.

SSH is useful for a lot of things, but I prefer the rsync daemon for rsync.

IIRC backuppc can handle the hardlink issue via rsync (rsync can preserve hardlinks, softlinks, etc...), but if not then your best bet might be to install something more NAS-friendly.

I'd not recommend installing Debian.  It's possible, but the machine is quite limited in CPU and RAM, so the experience is likely to be somewhat frustrating.  Most of the people who install Debian are running Terastations, which have desktop CPU's rather than ARM chips (and cost 5 times more).

On 07/10/2011 10:42 PM, Mark Phillips wrote:
> In the shared folders section, one can check Windows, Apple, disk backup,
> ftp, and sftp. When I clicked Windows and backup, rsync works.
> 
> mark at orca:~/Desktop$ rsync SANY0002.JPG rsync://xxx.xxx.xxx.xxx/array1_fred/
> mark at orca:~/Desktop$ rsync rsync://xxx.xxx.xxx.xxx/
> array1_fred
> mark at orca:~/Desktop$
> 
> The file was copied to fred, as verified by ftp.
> 
> Thanks for the link. I am worried that backup files will loose their
> ownership attributes when I back them up, as the poster says:
> 
> "Yes, you can use rsync on another machine to connect to the rsync-enabled
> shares on a LSpro; BUT all the files created by this method on the LSpro are
> owned by root/root and not by any of the users created on the LSpro, and
> there is no way to delete or update these files except by using the rsync
> command."
> 
> If I root the device and enable ssh, then I can rsync in via ssh and bypass
> all this Buffalo c**p, right? Backuppc also depends on hard links, so
> perhaps I have to go all the way and install Debian on the box?
> 
> Mark
> 
> On Sun, Jul 10, 2011 at 10:18 PM, Joseph Sinclair <plug-discussion at stcaz.net
>> wrote:
> 
>> For the mount, you can just use normal mount with -t cifs (or put it in
>> fstab with cifs as the filesystem type).
>> umount is generic; the unmount interface standardized a while back, that's
>> why umount.cifs is no longer in Debian, it's obsolete.
>>
>> For rsync, the module name will never have a space.  Given that it's not
>> showing up the way we expect, my best guess is the module naming changed in
>> the most recent revisions of the firmware.
>> It seems something odd is going on, quite possibly the rsync daemon is
>> running but no shares are enabled as backup targets.
>> According to the Linkstation forums on buffalo.nas-central.org, You have
>> to go into the backup section in the web interface and set each share that's
>> supposed to be available via rsync as a backup target (not entirely sure
>> what that looks like).
>> Here's the post I found:
>> http://forum.buffalo.nas-central.org/viewtopic.php?p=41941#p41941
>> It's not 100% applicable, but it should apply to your device fairly
>> equally.
>>
>>
>> On 07/10/2011 07:12 PM, Mark Phillips wrote:
>>> The only way I can gain access to the shares is to use the following. I
>>> created a new share called 'fred' and deleted the other shares:
>>>
>>> mount.cifs   //xxx.xxx.xxx.xxx/fred   /home/nas_share   -o user=user_name
>>> password=pass
>>>
>>> Of course, umount.cifs is no longer in Debian, but umount -f works to
>>> unmount the share.
>>>
>>> I cannot get rsync to work. According to the man page the following
>> should
>>> return a list of shares:
>>>
>>> rsync rsync://xxx.xxx.xxx.xxx/
>>>
>>> Nothing is returned (eg a blank line). I tried telnet xxx.xxx.xxx.xxx 873
>>> and I got the rsync response @RSYNCD: 30.0, so the daemon is running, I
>>> suppose.
>>>
>>> The following all return 'unknown module' regardless of what name I put
>>> after the url (array1_fred, , array0_fred array2_fred)
>>>
>>> rsync some_file rsync://xxx.xxx.xxx.xxx/array1_fred/
>>>
>>> or a '/' instead of a '_' returns the same error for module array1,
>> array2,
>>> array0. I also tried Array[0,1,2] with the same result. Some of the web
>>> pages show the name as Array 1, so I tried the capital A and a space, but
>>> still not luck.
>>>
>>> When I ftp into the box, the path to fred is xxx.xxx.xxx.xxx/array1/fred.
>>>
>>> I tried restarting the Linkstation, and no change.
>>>
>>> I also tried the alternative rsync format, rsync some_file
>>> xxx.xxx.xxx.xxx::array1_fred, and that did not work.
>>>
>>> Any more ideas on how to get rsync to work?
>>>
>>> Thanks!
>>>
>>> Mark
>>>
>>> On Sun, Jul 10, 2011 at 1:15 PM, Joseph Sinclair
>>> <plug-discussion at stcaz.net>wrote:
>>>
>>>> Dash and underscore are fine.
>>>> The only way to "reset" the name using the standard web interface is to
>>>> delete the share and re-create it with the new name.
>>>>
>>>>
>>>> On 07/10/2011 11:23 AM, Mark Phillips wrote:
>>>>> Can the share name have a dash or underscore in it? How can I "reset"
>> the
>>>>> share names?
>>>>>
>>>>> Thanks for all your help!
>>>>>
>>>>> Mark
>>>>> On Jul 10, 2011 10:59 AM, "Joseph Sinclair" <plug-discussion at stcaz.net
>>>
>>>>> wrote:
>>>>>> The info folder is used by the web interface; don't delete that unless
>>>>> you'd like to reload the device from scratch ;)
>>>>>> The correct value should be array1_Hshare. array1_Hshare is the rsync
>>>>> top-level "module" name, not a directory.
>>>>>>
>>>>>> The issue you're seeing sounds like a case-match issue or something
>>>>> similar. The module will be exactly "array1_" followed by the (initial)
>>>> name
>>>>> of the directory on the array.
>>>>>> If you initially put spaces in, or changed the name, then you'll have
>> a
>>>>> hard time figuring out the module name because it's based on the first
>>>> name
>>>>> you give for the share; it doesn't get updated if you change the share
>>>> name
>>>>> later.
>>>>>>
>>>>>> Also, if you changed the RAID settings, then try using array2 or
>> array0,
>>>>> just in case it changed the array numbering.
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------
>>>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>>>> To subscribe, unsubscribe, or to change your mail settings:
>>>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
> 
> 
> 
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20110711/9be75b40/attachment.pgp>