Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About rcfa

  • Rank
    Occasional Forum Poster
  1. Sure, that's what I conclude. But I consider that a bug, because just because /Volumes is the default location for automounted volumes, it's by no means the only place to mount volumes. If Retrospect were some cheap desktop backup solution for $20 from the AppStore, then I might tolerate that sort of behavior, but with something that's supposed to be enterprise-class backup solution, it's clear that even in the age of 5TB disk drives, a logical Unix-like file system hierarchy may need to be pieced together from multiple drives in a large server installation, e.g. boot drive, and then mounting a 30TB RAID-6 on /Users/ Auto-mounting these things in /Volumes and making a symlink won't work, because OS X (which I also consider a bug), expands all symlinks it encounters. Thus various parts of the OS throw hissy-fits because they do not recognize ~someUser when /Users/someUser ends up being expanded to some other location. That and similar matters make it impractical or impossible to use the /Volumes/ as mount points. What I do is the inverse: make symlinks from /Volumes to the real mount points. The problem with that is, that after each reboot these symlinks are cleared, so I have to employ startup scripts to recreate these symlinks after each boot. All in all, a rather obnoxious sort of workaround... Yikes....
  2. Here's what happens: Our clients mount, to seamlessly extend certain critical sections of the file system hierarchie with RAID-6 support, volumes at custom mount points, such as not to interfere with OS X default paths. The resulting /etc/fstab entry looks as follows: cat /etc/fstab # fs_spec fs_file fs_vfstype fs_mntops # # UUID=01234567-89AB-CDEF-0123-456789ABCDEF /export ufs ro # UUID=01234567-89AB-CDEF-0123-456789ABCDEF none hfs rw,noauto # LABEL=This\040Is\040The\040Volume\040Name none msdos ro # UUID=01234567-89AB-CDEF-0123-456789ABCDEF /Applications/Folder\040with\040spaces\040in\040name hfs rw,auto,suid,nobrowse UUID=01234567-89AB-CDEF-0123-456789ABCDEF /Users hfs rw,auto,suid UUID=01234567-89AB-CDEF-0123-456789ABCDEF /Users/Shared/Pictures hfs rw,auto,suid (Of course the UUIDs are the real volume UUIDs, which I replaced here with placeholders) When connecting to the client with the server, I can look at the list of backup sources, and I can see the clients root volume, and also the volume named Users and the volume named Pictures, as well as automounted volumes from a variety of external drives. I can list the files/folders in both the root drive and in all the automounted volumes, but when I want to list the contents of the Users volume or the Pictures volume, they show as empty, which of course, they are not. This effectively prevents us from backing up the most important part of the entire client: the /Users file system hierarchy! Needless to say, I sent in a support request, but all I got back was this somewhat laconic answer: The response is for one trying to restate a massive bug as a feature, and also makes no sense, because file systems mounted to user specified mount points with the /etc/fstab mechanism are visible perfectly fine in /dev/ and using /etc/fstab is perfectly supported by the OS X (it works even in iOS!!!) and is if anything the original standard way of mounting any file system. If anything is non-standard in a Unix system, then it's some proprietary automount demon. I'm posting this here in the hope that someone who actually does coding for Retrospect and understands what I'm talking about is reading this and ends up fixing the bug, because this certainly *IS* a bug, not a feature or even a limitation. A backup software that wants to be taken seriously simply has to support something as standard as this.
  3. It's "Completing restore..." for 11 hours now, and no sign of being done! No messages that say WHAT it's doing (checksums? permissions? links? modification dates/times? ACLs? Finder bits? Forks? sending data to big brother?), no progress bar indicating how LONG it's going to take (the backup progress bar is full, indicating that it should be done, since it already restored all the files). It's just doing something, takes forever, and leaves the user completely in the dark as to what's going on. Is this a way to make us pay for expensive per incident tech support, because obviously, there's nobody that will take a call for free regarding something that clearly is a shortcoming of the software! People are breathing down my neck asking when it's done, and I can just shrug my shoulders looking like a fool!
  4. Here's what happened: Machine zeus is an Xserve with the Retrospect server software 6.1.x and an Xserve RAID that serves as a file backup repository (mounted as regular 2.5TB drive named hera on zeus). This machine is running Mac OS X Server 10.4.4 Machine eos is a 12" PowerBook G4 attached via GigaBit Ethernet to zeus, this machine runs Mac OS X 10.4.4 Machine "apollon" had disk corruption due to some sort of OS crash, etc. The machine is a G5 with two SATA drives that are working as an Apple software RAID 0, i.e. like a single drive of nearly 500GB capacity. Machine appollon is in FW target drive mode, attached via FW400 to eos. apollon's RAID was wiped, and the entire apollong disk snapshot was supposed to be restored over the network from zeus/hera to eos/apollon, via "replace entire" mode. Surprisingly enough, despite near zero other network activity, this was somewhat slower than expected (just about 120MB/min or about 2MB/s) Not sure if that's the limit of the disk drives, because the network surely should be able to supply data faster than that. Anyway, now after a few days and 1156293 files and 429.1GB worth of data restored, I have this situation: Completing restore... and the file names go by about one per second. You can imagine, if we have to wait about 1156239 seconds, we'd be waiting 321 hours, or about two more weeks for the backup to finish!!! What is Retrospect doing at this point? Just doing checksums or stuff like that? Premissions? Hardlinks? Why is there no progress bar? I have no idea if it actually has to process all 1156239 files, or just a few hundred "special" files. If I stop and restart the backup, will it do whatever it's doing now, just faster, or will it just realize the files are there and never do whatever it's doing now? Can't really find anything on Dantz/EMC's web site that would shed light on this issue... Greetings, Ronald PS: Unrelated, but for incremental backup over a slow internet link (DSL 384kit/s), is there a way to throttle the speed, such that backups don't always fail with "Net retry" errors?