For extended attributes, how does this affect the backup of ACLs? If you specify an ACL on an directory, define that ACL as applying to all sub folders and files, and then use Mathusalem to backup the directory only the ACLs on the files will be copied? If you haven't tested I will have time later to give it a go.

I don't know if ACLs can be recursive or if they must be (re)defined at each directory level. You can double-check with the "xattr" command line tool.

In any case, I'm pretty sure ACLs are stored in the extended attributes of the directory and would therefor be stripped.

I am not sure I correctly understand the "initial backup space" item above. Does that mean, if I want to use mathusalem to backup a 400g music drive that the boot drive will also need to have 400g of extra space available?

That's correct: the current implementation takes a full snapshot of what to backup it then creates an archive from. The only exception is if you backup using sparse disk images to a local disk (in this case, it backups directly into the sparse disk image bypassing the snapshot).

The "initial backup space" limitation above is actually a quite dangerous issue: today I got my boot volume fill up to saturation thanks to Mathusalem just for the reason that my backup size was superior to the free space on my boot volume... And when it occured, Mathusalem did not handle this event in a secure way: it just displayed thousands of error dialogs. When do you plan to get rid of this limitation? And a second question about another limitation: when do you plan to preserve owner and permissions?

See  issue #64  on not starting the backup unless there's enough free space on the scratch disk. Note that this should only be a problem when trying to perform very large backups.

There are no plans to preserve owners and permissions: Mathusalem is not a cloning tool, but a file backup one designed for everyday simple backups, not the cloning of an entire file system or a subportion of it. Owner, permissions, ACL are metadata unrelated to the file content itself, which is what most user really care about (you wanna save your documents & photos, not their permissions). If you care about such metadata, you need to use a different backup tool.

I am not sure I understand why for the initial backup why there needs to be a "snapshot" copy before copying the files to the backup disk. As the initial back needs to copy everything and not any deltas of changed files why does it not just copy directly to the backup disk. Also can one not pipe the output of rsync through to zip or what utility that is chosen to create the backup images on the backup disk. This limitation, that seems to be in every backup application, is what always prevents me from using them to backup large files or large directories.

Other that - very nice implementation.

Mathusalem does not use rsync but a custom backup file engine. The snapshot is needed because you can only pass a directory (and not a list of files) to ditto or hdiutil.

Mathusalem will skip the snapshot only if you choose Sparse Disk Image as the backup format (as in this case, the archive is writable). The downside is that such archives are not compressed.

yes I see, however for the FIRST backup, we wish to backup the complete directory so you can pass that directly to ditto or hdiutil and pipe to zip ( or what compression engine ) then for the delta backups, you make the snapshot etc This could be a user option. Use at risk - or less risk as there is less file copying The Mathusalem will be perfect.

michael - on the rampage for hopefully the first perfect backup utility

That's still not robust as 1) behavior of ditto or hdiutil when some files are not-copiable for whatever reason is not necessarily predictable, and 2) they don't provide either the list of files and directories that ended up being copied, which is needed for the backup BOM.

Can it mount the AFP server? For laptop users its a must since they wont always have the drives mounted when the schedule to run kicks in.

If you choose "AFP Server" as the backup destination, yes, Mathusalem does auto-mount and unmount.

I understand Mathusalem is not intended for cloning, but what is the rational behind restricting it from treating a user folder (/Users/foobar) as a source directory path? It would be nice to be able to backup / archive a user's entire home folder as OS X places many user-specific folders (Photos, Music, Documents, etc.) under here.

It's fine to backup the entire home directory as long as you exclude the proper subdirectories like Library/Caches, Library/Logs... and that Mathusalem has the right settings. Otherwise, you can easily have Mathusalem in an infinite loop, trying to backup files that are continuously changing for instance.

I receive the following warning when I try to set the source directory to "/~" or "/Users/foobar": "Mathusalem is not designed to clone an entire disk or an entire user directory. Please select a specific directory you want to backup (you can always create multiple backups)."

What are the "right settings" you speak of?

You cannot backup the entire home directory from the UI, it's not allowed.

Regarding the settings, you probably want to have atomic backups off and ignore hidden files off as well, but again, Mathusalem is not designed to "clone" a user directory or entire volume, so even if it might work fine, there's no guarantee that if you were to restore the backup completely, things would work exactly as with the original.

Thanks for your prompt responses. I really like what you've created and am super grateful for Mathusalem! That said, could I make a feature-request to allow entire home-directory backups from the UI? As I mentioned earlier, I understand the caveats w.r.t. cloning. This is more about dealing with OSX's folder structure of putting Music, Photos, Documents, etc. under the home directory and not having to create separate backup plans for each one.

When you say the UI restricts this, but that "It's fine to backup the entire home directory as long as you exclude proper subdirectories ..." - are you suggesting to go about this via the CLI version?

Regardless, would be nice to be able to backup a home directory via the GUI version even if there's no guarantee w.r.t. cloning.

You can indeed use the CLI version of just hack the .plist created by the UI in Library/LaunchAgents?, but at your own risks obviously.

Hello, I find your tool really great, it is exactly what I was looking for. I just wanted to know if you plan to add a file rotation option. I mean a possibility to automatically remove backup older than x days. I search but could not find this. Again thanks for your great tool. If you search for someone to translate in French and Italian, just ask, I would be happy to help you.

No, there are no plans to add such a feature as it would be a complex change to Mathusalem backend, sorry

Great app. I wonder why only archives formats are offered, why can't I backup my files as regular files?

Because this app is designed to backup primarily to remote servers and it's more reliable to upload archives than a bunch of individual files (especially if you need to preserve things like resource forks).

Good afternoon. Thanks for this great application. I have a question regarding usernames and passwords used for accessing iDisk? I noticed that when I don't provide a username/password then Mathusalem accesses KeyChain? to get the information for my .me account. That's a good approach. How about the other accounts? Are these stored encrypted and do you use Keychain? I guess it's the same question for usernames and passwords for accessing SFTP, WebDAV, etc.

Valentin

Usernames are stored within the backup config file in ~/Library/LaunchAgents? and passwords are stored in the user's Keychain.

MobileMe? is the exception as the login / password for this service is directly available from the Keychain.

I've been looking for a backup application that's simple and complete for a long time. Mathusalem fits the bill... but for one thing: I want to backup my whole user account, what else?

Even if completely restoring an account wouldn't be adviseable, completely backing it up would reassure me that everything is saved that needs to be saved, and worry later about splicing the really important bits from ~/Library back into a newly installed user account. Think Mail mailboxes, think iCal calendars...

As for often-changing files: shouldn't deselecting the 'atomic backups' take care of that?

Maybe there could be a special mode for user accounts, which is non-atomic and skips some standard cache directories?

I am using Mathusalem with enthusiasm....

I tried to set up a backup using the Schedule: Run Every t? hours.

However i wish to have this on a laptop that is not always connected to the external disk. It idid not seem to kick in after t? hours when woken from sleep or shutdown. Perhaps I did not have it configured properly....

Does Mathusalem "Run Every..." options run once the "Run Every..." time option has passed or only if the computer is awake at the time. If not can this be added as an option to "Run Every..." at least ONCE, on system wakeup or whenever the time event has passed.

Then Mathusalem is perfect ;-)

Michael

"Run Every..." runs every X hours. If the machine is asleep, it will run at the next time it is awake, and then X hours later again.

yes, this is what I would under it to do, but somehow it was not doing this.

Playing around just now on my MacBook? Pro I noticed that unless one hits the "Enter" button the number of hours does not take, ie it shows eg 4 hours, but it really still has 24 hours ( the default ) entered. I tested this by selecting "Run Manually" then returning to select " RUn Every". ONly if I enter the new values then hit "enter" key does the new value stick. Perhaps Mathusalem could take the new value on mouse click or a note to use the "enter" key.

Secondly I wonder if the "Run Every x hours" when awaking from sleep checks the hours but if the external hard drive has not yet mounted then Mathusalem does not run and that was the reason I did not see the backup running. If this is the case ( needs to verified ) then Mathusalem perhaps need modifying to use a combination of "Run Every" and "Run when both drives available". Again perhaps Mathusalem has this already but it would be nice to know for sure as I did not see any backups while I had "Run Every" selected.

Does Mathusalem have a log file where I can check what was happening. I plan to test things here, but my brothers laptop is in New Zealand so it is now so easy to config and test it as I now back in Palo Alto.

Michael

hmmm,

perhaps the problem is that in the History and Restore view the backup are not always listed.

On my 24/7 server I have a backup that runs everyday of the week at 3AM. If I look in the destination directory i do indeed see the Revisions_002... etc was it should but in the Mathusalem History and Restore I only see Revision1? listed, not the others that do show in the destination folder.

Should i submit this as a bug?

michael

Yes, please submit a bug

salut,

any plans to implement bzip2

benefits: - good compression - very fast decompression

downside of slower compression is not much of an issue as this task is mostly performed in as a background task.

http://en.wikipedia.org/wiki/Bzip2

michael

You can submit a bug about this if you wish.

Salut,

Mathusalem works fine on my side on a AFP server. I now want to schedule backup every night, but does not work since I have to fill admin password every time for hdiutil app. Do you know from where it comes from and how to resolve it ? (note : the account used to run mathusalem is an admin one)

thanks for your help Thomas