# Full backup of a live FreeBSD server?



## BLuFeNiX (Jan 15, 2013)

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!


----------



## kpa (Jan 15, 2013)

Use dump(8). Warren Block a has nice guide for such backups at:

http://www.wonkity.com/~wblock/docs/html/backup.html#_em_dump_8_em_em_restore_8_em

If you're on FreeBSD 9 you should turn off softupdate journaling (also known as UFS SU+J), otherwise the snapshotting of a live filesystem might hang. This can be done with tunefs(8), preferably in single user mode when the root filesystem is still read-only.

`# tunefs -j disable /dev/ada0s1a`


----------



## BLuFeNiX (Jan 15, 2013)

Thanks! I'm going to try it today.


----------



## phoenix (Jan 15, 2013)

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.


----------



## wblock@ (Jan 15, 2013)

If you use net/rsync, the newest version of the port has a patch that lets rsync overwrite files with the schg flag set.  Build the port with the FILEFLAGS option, and use --fileflags.  So it is now possible to rsync over an existing /bin and other directories with FreeBSD schg flags.


----------



## phoenix (Jan 15, 2013)

Nice.  Did not know that.  Thanks for the tip.


----------



## wblock@ (Jan 15, 2013)

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.


----------



## KernelPanic (Jan 16, 2013)

You may also want to consider sysutils/rsnapshot.  It also uses rsync.


----------



## WiiGame (Jan 28, 2013)

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.


----------



## wblock@ (Jan 29, 2013)

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.


----------



## WiiGame (Jan 30, 2013)

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.)


----------



## wblock@ (Jan 30, 2013)

Sure.  No reason to cringe, most FreeBSD users are pragmatic.  If it works, it works.


----------



## kpa (Jan 30, 2013)

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.


----------



## WiiGame (Feb 14, 2013)

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?


----------



## wblock@ (Feb 14, 2013)

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.


----------

