Full backup of a live FreeBSD server?

Hi,

What's the best way to do a full backup of a live FreeBSD server? Should I tar the entire filesystem (which directories should I exclude? /proc, /compat, etc.)

I have also heard of a utility called dump. Is it better suited for a live system backup?

Thanks!
 
rsync also works well for this. It's what we use to backup all our FreeBSD and Linux systems. Search for "rsbackup" in the forums for more info on how we do it. ;)
 
It's a brand new addition to the port, although the bug and patch have been around a while. It just had to become motivating enough that someone (ahem) went looking for solutions, tested, and notified the port maintainer, ehaupt. Who, it should be added, did a quick job of integrating it into the port and deserves thanks for keeping one of the most useful ports we have up to date.
 
I have a related follow-up to this. It's not an exact match but I'm not sure if it warrants its own thread (and this is the closest thread I could find to it).

If one is running FreeBSD as just a basic home Windows/Samba file server, with the basic install OS on a flash drive (everything else on HDDs), and one has no other UNIX-based systems in the house, is the above the best way to approach backing up the flash drive/OS? If so, this relates directly to the live backup OP.

Or is there another way, such as taking an offline backup/snapshot by sticking the flash into a Windows PC and somehow making an image of it to be the replacement when the flash drive dies? On the surface, this sounds easier (given the OS drive can move freely, the mostly static nature of the OS data, and the Windows env) but I don't know if it's even possible.

BTW, one = me, of course. But I'd think I'm not the only one.
 
An image backup is as big as the media. It can be compressed, but it still copies a lot of empty blocks that are not being used. A backup with dump(8) is not as simple, but only copies blocks that are in use. Windows programs like Acronis should be able to make an image backup.

Don't forget that dump(8) can be used from a script. So it doesn't need to be a bunch of typing every time it's used.
 
Good point. Thanks again. I'd guess this will make avid UNIX folks cringe, but dump-ing to a Windows share over Samba with FreeBSD as a client should work, right? mount_smbfs? (I wouldn't want to dedicate a disk for 5GB in an otherwise all-Windows env.)
 
I used to do that when I had a small NAS device that didn't support any other file sharing protocol than SMB. It wasn't optimal but it worked.
 
I did do this and it worked ... for the whole thing ... however, when I wanted to use dump to just get one branch I previously skipped with nodump (e.g., /usr/ports or /usr/src), dump won't let me get it because it's not a "filesystem". I guess after all these years I still don't get the difference between a filesystem (that's not a partition or a whole disk) vs. a branch off the directory tree (they all look the same to me), or how to tell one from another, and the handbook was not very helpful to me here. My dump wouldn't even let me do /usr or /var separately because they are somehow not "mountable filesystems" in my default install.

So I could get the whole thing at once, but what if I just want a piece. Is that the time for rsync?
 
A filesystem is what is created when newfs(8) is run. They are in a fixed portion of a drive. /etc/fstab has an entry for each filesystem on your system. Understanding how mount(8) mounts a filesystem on a mountpoint (really just a directory) may make that clearer.

A default install of FreeBSD 9.1 has only one filesystem, /. It has subdirectories for /var and /usr, but those are part of the same filesystem. An old-style split-filesystem install creates separate filesystems for /var and /usr, then those others are mounted over the same-name directories on the / filesystem. They appear to be part of the same directory tree, but are really in different partitions on the disk.

rsync(1) is a better choice for pieces of a filesystem. Depending on what is being copied, tar(1) is also popular.
 
Back
Top