NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
GeoffSB
May 07, 2021Aspirant
Remote drive backup infinite loop?
I am trying to backup from a remote shared network drive as Source to a folder in a NAS Share. The settings and permissions are all good and the test connection works fine. Problem comes when I execu...
GeoffSB
May 07, 2021Aspirant
Thanks for replying
StephenB wrote:
GeoffSB wrote:I am trying to backup from a remote shared network drive as Source to a folder in a NAS Share. ... I can't use RSync
What backup protocol and settings are you using?
I was using the Windows/NAS(Timestamp)
I'm assuming you mean that you can't use rsync over ssh, as vanilla rsync doesn't need a public key.
OK - not an expert - tried looking at RSync as it apparently has options to exclude folders, so thought this might be a workaround. The remote is a corporate SAN facility so I do not have any administrative permissions on this system. I am creating a backup for longer term storage of data as the SAN isn't big enough for this and is a more active working space. I didn't try the 'vanilla' RSync
GeoffSB wrote:
The only issue I can see is that the Remote drive has a .snapshots folder. The directories in this folder seem to be writing when I am trying to backup with the NAS - they are not part of the remote drive. The log for the backup reports errors trying and failing to access files in these .snapshot directories. I can't find a way to delete the .snapshots folder on the remote drive.
What I mean is that I don't think (could be wrong) that the remote drive natively keeps snapshots. If it does, then it seems odd that the only directories in this folder align with the times where I have been trying to run backups from the NAS. It looks like the NAS is making it write to the .snapshots or it is the NAS that is writing it. Either way it doesn't make much sense to me.
UPDATE
I switched to Windows Archive Bit - I also noticed a 1h time discrepancy with the NAS system as it was linked to GMT rather than London time so wasn't on British Summer Time - fixed this issue. The Backup now appears to be working. Not sure if it is the different protocol or if the time fix prevented some infinite loop of snapshots.
GeoffSB
May 07, 2021Aspirant
Not all of my post seemed to get posted - got confused with attempting to including quotes in replies...
I was previously using Windows(NAS) Timestamp
I didn't try the vanilla form of RSync. I'm not an expert - as you probably gathered - I read that RSync can exclude specific directories so thought this might be a workaround. The remote is a corporate SAN drive so I don't have any administrtive priveleges.
- StephenBMay 07, 2021Guru - Experienced User
GeoffSB wrote:
The remote is a corporate SAN drive so I don't have any administrtive priveleges.
Got it.
GeoffSB wrote:
I read that RSync can exclude specific directories so thought this might be a workaround.
Rsync would let you exclude directories. Ordinary rsync backup jobs are not encrypted, so they don't need a key installed. But of course that means you shouldn't use ordinary rsync over the internet. It'd be fine the NAS and SAN drive are connecting over your corporate network.
GeoffSB wrote:
What I mean is that I don't think (could be wrong) that the remote drive natively keeps snapshots. If it does, then it seems odd that the only directories in this folder align with the times where I have been trying to run backups from the NAS. It looks like the NAS is making it write to the .snapshots or it is the NAS that is writing it. Either way it doesn't make much sense to me.
I don't use Windows backup protocols myself, so I don't recall off-hand how it handles hidden folders like .snapshots.
On the ReadyNAS side of things, shares (and snapshots of shares) aren't ordinary folders - they are BTRFS subvolumes. Normal linux commands won't delete them.
But on my ReadyNAS (currently running 6.10.4), I don't see a .snapshots folder when I look at the share with ssh. I do see a snapshot folder if I have "allow snapshot access" checked in the snapshot settings, but not .snapshot.
As an aside, I don't check the "allow snapshot access". It not only makes the snapshots accessible, it also makes them writable. That defeats their purpose as far as I am concerned. I do check "allow access to Windows Previous Versions".
- GeoffSBMay 07, 2021Aspirant
Unfortunately I cannot connect with the vanilla RSync - it won't accept my login details. So I guess the SAN isn't setup to accept this protocol.
When I did the backup with the Windows Archive bit, it seemed to work, but the GB of data was somewhat different and less on the backup than on the source (as measured in Windows Explorer).
Is there a way of getting Directory size in the NAS OS? That would be really useful!
I am rerunning now having gone back to to Windows(NAS)Timestamp protocol. Will see if it runs forever....
- StephenBMay 07, 2021Guru - Experienced User
GeoffSB wrote:
I am rerunning now having gone back to to Windows(NAS)Timestamp protocol. Will see if it runs forever....
If it does, maybe check the time sync between the SAN and the NAS.
GeoffSB wrote:
Is there a way of getting Directory size in the NAS OS? That would be really useful!
If volume quota is enabled on the volume settings wheel, you can see the on-disk space for each share. This is in a "consumed" column in the shares page. This size includes snapshot space (if snapshots are enabled). The file system is likely different from the SANs, so the results might not tie out exactly.
FWIW, when you access the share via Windows, there is some translation going on in Samba (running on the NAS), and the space won't be that accurate. That might also be true with the SAN. You could download a sample from both, and then diff them I guess.
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!