Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yikes. It sounds like you are in a constant state of trying new file systems and backup solutions. Why not simplify and go with a good enough solution?

Personally, I like zfs and rsnapshot. That is what I use on my NAS and it seems to work without me spending time one maintaining it after the initial setup. Why rsnapshot and not snapshots of the zfs volumes? Because I want to keep lots of backups and my understanding is that zfs loses performance after you cross into a few dozen snapshots on the type of hardware I have.

Now, I never understood backing up your home for. Why? I keep any documents on the NAS (thanks VPN and ssh for making life easy here), dot files on GitHub, and source code in git with origin on either GitHub or the NAS depending on if it is private or not. Chat logs are going to be my one exception, but perhaps the servers will back them up for me instead a la GChat.



You're right, there's a lot going on, but -- and you are just going to have to believe me on this -- each method gives me something the others don't. As will ori. And honestly, I don't mind the extra moving parts: having recently suffered a catastrophic drive failure that set my business back a quarter, I am okay with a never-too-much-overkill approach to backups.

My problems number two: On the first hand, there are often bizarre interactions between versioning systems when they are hosted atop of one another, breaking encapsulation in unexpected ways. You can't use .vmdk snapshotting on btrfs, for example, because the performance is whatever the opposite of 'breathtaking' is. (Sighgiving?) Meanwhile, a git repo on a Dropbox share is going to chew itself to pieces the first time there's an fs-level merge conflict in .git. I could go on.

The second problem is the flip side of the first -- there is no way of importing and exporting history between versioning systems. I shouldn't worry about git and dropbox: dropbox should offer itself as UI for git.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: