Take the 2-minute tour ×

I have a copy of FreeNAS running off a live USB disk. And I'd like to make a backup of it.

While trying to avoid breaking a perfectly working system, would I be able to dd the disk while the OS is running?

Or would I have to shut the machine down and run dd off another machine?

share|improve this question
add comment

4 Answers

up vote 5 down vote accepted

You can run dd on the running disk. Doing so when there are heavy changes to the disk structure should be avoided. Also you should fschk the destination once you are done. The quieter the system is during the backup the better.

Running a cold backup (file system unmounted) is the best option if you want to use `dd'.

There are better options for backing up a running system.

  • tar or cpio will read the files and deals reasonably well with open files. You will likely miss some of the changes which occur during the backup.
  • rsync behaves like tar in respect to open files, and missing changes during the backup. It can be used to do the initial backup and does incremental backups very well. When running an incremental backup it can skip copying unchanged portions of file.

If you are backing up a file system with database datafiles investigate support for hot backups.

share|improve this answer
Good points on using higher-level tools - tar, cpio and rsync all work within the filesystem, so this may be appropriate. dd, OTOH, works directly with disk blocks, bypassing the FS. –  Piskvor Mar 4 '12 at 16:26
add comment

It is technically possible (as in "shooting-yourself-in-the-foot"), but highly unadvisable, especially if any of the disk's partitions are writable.

Picture this scenario:

  • dd starts reading the disk at the start, and merrily makes its way towards the end.
  • When it's halfway there, the OS writes a file to the disk. The file is somewhat fragmented though - one part of it is physically located towards the beginning of the disk, and another towards the end.
  • No problem for the OS - it writes the file just fine, and pushes it out of its write caches; it is now correctly written on the disk.
  • The problem is with your backup: dd has already gone past and copied the first part of the file, so it will capture an inconsistent state when it gets to the second part - each part will be from a different version!

If you're capable of remounting all the partitions on the USB disk as read-only, this problem shouldn't occur (emphasis on "should not"); this requires significant up-front install/offline preparation and boot-time setup for the / partition though - I don't think you can normally remount / r/o on-the-fly, there will be multiple things hanging off that requiring r/w access.

So, running the copy probably won't break the running system, but won't give you a workable backup, rendering the task moot. I highly recommend making the copy offline - which would require shutting down the machine.

share|improve this answer
Thanks for a great answer, I was hoping for an easy way out, but you are correct, I can't imagine a good scenario arising out of what you pointed out. –  stuartc Mar 4 '12 at 16:49
@stuartc: It would require major cooperation from the FS driver - informing the copying process of every change that has happened since the copy started, and whether it gets to a consistent state. If this is a major issue, look into filesystems which support snapshotting, such as btrfs. –  Piskvor Mar 4 '12 at 16:54
add comment

You should never create an image of a mounted partition. No matter if you booted from it or not.

But you'll have a hard time trying to unmount the partition you booted from.

share|improve this answer
add comment

For this, I use dump(8) on FreeBSD. E.g. dump -auLf /mnt/some-other-disk/root.dmp /

The -L option allows the copying of a live file system by taking a snapshot.

The dumps can be restored by using restore(8).

It might only work with UFS; I am not sure about that.

share|improve this answer
add comment

Your Answer


