Talk:Full system backup with rsync
Page title does not use naming guidelines. Also, a forward slash between two words defines an either/or option (e.g. Backup for full/partial configurations) which I don't think is meant to be the case here.
--Gen2ly 06:16, 12 December 2009 (EST)
- The slash was supposed to be a subpage. It looks like that's disabled in this wiki for article namespace (as it is in Wikipedia) so I'll just change it. Time 07:05, 12 December 2009 (EST)
- Full System Backup with rsync? If not, go ahead and change it. Time 07:14, 12 December 2009 (EST)
- Just got a chance to read the article, nice work.
- --Gen2ly 14:32, 13 December 2009 (EST)
Thanks User:Time for taking the time to rewrite this :) It looks good and it's more generic now, also thanks for keeping the link to the original forum post.
- I vote for moving this page back to its initial title (Full system backup with rsync) since it can't be merged with Rsync.
Wooptoo 13:26, 23 December 2009 (EST)
I cannot move it back to the same title without admin intervention. They have to delete the redirect first. Sorry for changing the name in the first place; I didn't realize subsections worked only for user pages. pwd 13:27, 23 December 2009 (EST)
- Oops! Sorry; didn't realize that was the cause of the hold-up. I've removed the redirect. -- pointone 13:34, 23 December 2009 (EST)
- Moved the page even though I don't like the title. I really don't think the naming scheme suits it; should be Full system backup with rsync, in my opinion. pwd 14:10, 23 December 2009 (EST)
Thanks! Neat method for a sync-type backup! The only question I have is what happens if you
dd the boot sector (first 512 bytes) instead of running GRUB? --VitaminJ 22:18, 11 November 2009 (EST)
I don't know if it works with
dd, since the partitioning scheme can be different on the two harddrives.
- I vote for merging this with rsync.
- I second the vote.
Yep, I think you are right, I think that GRUB hardcodes the path to menu.lst in the GRUB boot program, so if you change around disks it won't work.
As an alternative, an article on using tar instead might be useful because rsync may improperly preserves permissions across filesystems. For example if you backup from ext3 to XFS, and try to restore back to ext3.
- The only issue would be doing it with FAT or NTFS were permissions just aren't possible. Coincidentially, I've done this exact setup using XFS and ext4 wihout anything breaking down. I only had problems between reiserfs and *, but that was due to SELinux context. Dres 21:22, 18 January 2010 (EST)
I think its a good idea to mention dirvish here. --Moere 03:37, 1 March 2010 (EST)
on the same topic, you can also look at a free script that i wrote to backup the whole disk with rsync here: http://blog.pointsoftware.ch/index.php/howto-local-and-remote-snapshot-backup-using-rsync-with-hard-links/
It uses file deduplication thanks to hard-links, uses also MD5 integrity signature, 'chattr' protection, filter rules, disk quota, retention policy with exponential distribution (backups rotation while saving more recent backups than older). It was already used in Disaster Recovery Plans for banking companies, in order to replicate datacenters, using only little network bandwidth and transport encryption tunnel.
Can be used locally on each servers or via network on a central remote backup server. windows server could also be backuped by using a linux box that mount smb shares from them.
I'm getting the following error with this script, unless I use --delete-excluded, although that was declared unnecessary:
cannot delete non-empty directory: lib could not make way for new symlink: lib cannot delete non-empty directory: lib64 could not make way for new symlink: lib64