NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Time Machine
366 Topics
How-to: Setup multi-Mac backup shares with quotas. Easy.
Over the last couple years, I've been backing up each of my Macs to the default ReadyNAS Time Machine share. It's been OK, aside from having to hack my sparse bundles to stop them from increasing in size on their own. For some reason, as of Lion, I've had trouble getting that trick to work reliably. After a weekend of research and playing around I finally put together a good Time Machine setup for my three Macs. Rather than have all three computers backup to the default ReadyNAS Time Machine share, I've setup specific user accounts with quotas to limit the size of the Time Machine backups and I backup each computer to the respective user account home folder. Turns out with the latest 4.2.19 update (I have an x86 NAS) it's a pretty easy setup. I've now tested it with two Lion and one Leopard OS. (And as a test, I found that SSH and Unix know-how isn't necessary.) Figured I'd try to contribute something back to the forum. These steps assume that Time Machine support is already enabled on the ReadyNAS. 1.) Go into FrontView. Under Security > User Accounts I added a user account for each computer with a quota. (I tend to allocate 1.5x my computer's hard drive space for backups.) 2.) For each user, only two files needed to be created. Repeat the following steps for each user you create: 3.) Open a Finder window and open the AFP (or CIFS) representation of your ReadyNAS in the sidebar or Network folder. 4.) You'll probably be connected as "Guest" and might see any shares that are publicly accessible. Click the "Connect As" button at the top of the window and connect using one of the user accounts you created earlier. 5.) A folder should show up with the name of the user that you logged on as. That's the user's home folder. 6.) Using your favorite plain-text editor create a new plain-text file with a single line containing: /c/home/<username> ReadyNAS cnidscheme:dbd allow:<username> options:tm Replace <username> with the exact spelling of the user you're connected as. (It should match the folder name in case and spelling.) Save this file as .AppleVolumes in the user's home folder. 7.) Create an empty file called .com.apple.timemachine.supported and save it in the user's home folder. Note: both the files start with a . which won't show up in the Finder normally. Eject the ReadyNAS share when you're done creating those two files and connect as the next user if necessary. I found I didn't have to reboot the system to make the changes work for the next step. But it doesn't hurt. 8.) On your Mac, go into the Time Machine preferences. If Time Machine was already setup, go to Select Disk and choose "Do Not Backup" (this makes it forget the previous username/password that was saved). Then do Select Disk again and choose your ReadyNAS like usual. When asked for a username and password, connect using the user and password you setup for that particular computer. That should be it. Like I said, worked on three computers without a problem. No special settings had to be made on the computers. Sources: http://www.readynas.com/forum/viewtopic.php?f=71&t=57003 http://www.readynas.com/forum/viewtopic.php?f=10&t=55738 http://www.readynas.com/forum/viewtopic.php?f=71&t=5516617KViews1like64CommentsWork-around: Deleting Time Machine images
Forgive me if I've missed any posts, but when I was trying to figure out how to quickly delete a Time Machine archive image on the ReadyNAS a month ago (notably, before Lion or 4.1.8 came out) I didn't see anything on point. Deleting the archive via Finder is not only painfully slow (and you're lucky if it gives anything resembling an accurate estimate of time remaining), and rysncing an empty directory into the bundle's contents with the --delete --progress flags enabled does give a little more detail but isn't exactly speedy either. The ReadyNAS frontview doesn't give a quick option to delete the images, either. However, it does give an option to delete shares, and moving files between folders on a given share on the ReadyNAS is quite quick. So, to delete a Time Machine bundle quickly: 1. Create an empty share on your ReadyNAS (doesn't matter what you call it, I'll call it "Delete" in this example). 2. Log in as admin 3. Mount the "c" share 4. In Finder, hit -Shift-G and go to "/Volumes/c/.timemachine". You should see bundles for whatever computers are set up to backup via Time Machine. 5. The folder for the share will be at /Volumes/c/Delete, in this example » do not try to copy it to a separately mounted share, or all the benefits of this method are eliminated. Both the folder with the time machine images and the share from Step 1 are accessible via the "c" share, so you want to access both through that mount point. 6. Move the bundle you want to delete to the folder of the share you created in Step 1 (should be /c/Delete/, in this example). 7. Log in to Frontview and delete the share from step 1. You won't see the space reappear instantly - I'm not sure what file process the ReadyNas uses in the background to process the share deletion, but the space will be reclaimed over the course of a few minutes. The deletion doesn't require network interaction or for your computer to be on, however, and it is *far* faster than deletion via Finder or rsync. Hope this is helpful. Be very very careful you don't delete a sparse image you're still using - there's no way (that I know of, at least) to get it back! -Jamie6.8KViews1like20Comments
time machine OSStatus error 2
Hi I'm having a problem accessing my readynas nv+2 to use as a time machine backup I'm managing to get past the password stage when logging into time machine, whereby i get the error The operation couldn’t be completed. (OSStatus error 2.) This is a common problem from what I can tell, but I can't find a fix anywhere. any ideas? Thanks5.6KViews1like6Comments
ReadyNAS 6.9.4 breaks timemachine backup
Upgrading to 6.9.4 on RN314 has broken Mac timemachine backups using AFP on High Sierra. It also fails on El Capitan which worked previously. Failure mode is OSStatus 89 on the timemachine setup dialogue. I know that the Mac is seeing the timemachine volume and it fails as expected with an invalid logon. It makes no difference if a private timemachine is used, tried turning timemachine off and then on, change password, tried to use SMB, reboot ReadyNAS etc. etc. Downgrade to 6.9.3 and everything works, creates new sparsebundle and then backs up. This looks like an OS bug in 6.9.4.1.5KViews1like3Comments
remote Time Machine
Hi, How would it work to use remote Time Machine? I suppose Time Machine does not simply offer the remote share in the list of possilbe locaitons. Netgear says it is possible, but I can't find an explanation how to accomplish that. I have plenty of bandwidth...3.8KViews1like4Comments
RN104 OS 6.7.1 -> 6.7.4 breaks rsync backup of Time Machine to External Disk?
Our Macs use Private Time Machine on ReadyNAS, and we have been backing up the collective Time Machine "share" to external USB/eSATA disk using a remote: Rsync over SSH backup job (in the Admin Page). Like so, e.g.: ---------------------------------------- Backup Job Name: Time Machine (M W F Sa) Backup Job Type: Incremental Protocol: rsync+ssh Backup Source: [timemachine:~timemachine~]/ Backup Destination: [remote:rsync+ssh]/127.0.0.1://media/USB_HDD_4/TimeMachine/MWFSa Backup Start Time: Mon May 29 2017 2:59:41 Backup Finish Time: Mon May 29 2017 4:02:14 Backup Status: Success That above is actually the last successful run of this job, before upgrading ReadyNAS OS 6.7.1 to 6.7.4 on 5/29/2017 at 22:49. Since then, every time the job (and its (Su T Th) sibling) runs, it finishes in just a few seconds with a log entry like: sending incremental file list sent 177 bytes received 20 bytes 78.80 bytes/sec total size is 0 speedup is 0.00 and no actual data is copied. Testing quite a bit, I found that the fundamental problem is that the rsync backup job is copying at most only the top-level directories (i.e., not recursively), so if we have: /data/.timemachine/chris/ /data/.timemachine/ellie/lunitari.sparsebundle/ /data/.timemachine/tom/bacamac.sparsebundle/ /data/.timemachine/tom/phaedrus.sparsebundle/ ...running the backup job to an empty destination dir results in empty chris, ellie, and tom directories being created: sending incremental file list ./ chris/ ellie/ tom/ sent 159 bytes received 31 bytes 380.00 bytes/sec total size is 0 speedup is 0.00 After lots more experimenting and testing (incl. running rsync in a shell), I have found that it seems to be related to the --one-file-system option for rsync. Using an example rsync command I found in another thread, I was able to narrow it down to that option by comparing: root@NASbox:~# rsync -v -8 --timeout=30 --recursive --links --times --devices --specials --one-file-system --modify-window=2 --owner --group --no-acls --no-perms -delete /data/.timemachine/ /media/USB_HDD_4/TimeMachine/SuTTh/test sending incremental file list ./ chris/ ellie/ tom/ sent 159 bytes received 31 bytes 380.00 bytes/sec total size is 0 speedup is 0.00 and (removing --one-file-system option): root@NASbox:~# rsync -v -8 --timeout=30 --recursive --links --times --devices --specials --modify-window=2 --owner --group --no-acls --no-perms -delete /data/.timemachine/ /media/USB_HDD_4/TimeMachine/SuTTh/test sending incremental file list ./ chris/ ellie/ ellie/.AppleDB/ ellie/.AppleDB/cnid2.db ellie/.AppleDB/db_errlog ellie/.AppleDB/lock ellie/.AppleDB/log.0000000003 ellie/lunitari.sparsebundle/ ellie/lunitari.sparsebundle/Info.bckup ellie/lunitari.sparsebundle/Info.plist ellie/lunitari.sparsebundle/com.apple.TimeMachine.MachineID.bckup ... and off we go... ...and finally the weirdest part: It only misbehaves if the source dir is /data/.timemachine/. If it's a different path like /data/.timemachine/tom/ or even /data/.test/, it works as expected, even with the --one-file-system option: root@NASbox:~# rsync -v -8 --timeout=30 --recursive --links --times --devices --specials --one-file-system --modify-window=2 --owner --group --no-acls --no-perms -delete /data/.timemachine/tom/ /media/USB_HDD_4/TimeMachine/SuTTh/test sending incremental file list ./ .AppleDB/ .AppleDB/cnid2.db .AppleDB/db_errlog .AppleDB/lock .AppleDB/log.0000000106 bacamac.sparsebundle/ bacamac.sparsebundle/Info.bckup bacamac.sparsebundle/Info.plist bacamac.sparsebundle/com.apple.TimeMachine.MachineID.bckup bacamac.sparsebundle/com.apple.TimeMachine.MachineID.plist bacamac.sparsebundle/com.apple.TimeMachine.Results.plist bacamac.sparsebundle/com.apple.TimeMachine.SnapshotHistory.plist bacamac.sparsebundle/token ... ...and off we go... I understand that my example rsync command line is not exactly what is actually used by the backup job (e.g., no SSH and no snapshot), but I believe it is close enough to have worked in isolating the problem. I'm no kind of expert on btrfs and its snapshots, etc., but thinking hard about the --one-file-system thing and /data/.timemachine/ vs. /data/.timemachine/tom/ vs. /data/.test/, could this be related to the fact that /data/.timemachine is a btrfs subvolume? Anyway, to repeat: these backup jobs were working fine prior to the 6.7.1 -> 6.7.4 upgrade, and effectively fail every time since. Any ideas, or can anyone replicate? Thanks!Solved6.4KViews1like7Comments