Filesystem journaling and dump

[npgm]

Hello.

I'm pretty new to FreeBSD and not a whole lot experienced in the general Unix world. I wanted to practice backing up and restoring a system running FreeBSD 9.1, but I ran into a problem when I tried to use dump.

Snapshots are not yet supported when running with journaled soft updates.

I found this post, which was a little helpful. I understand that the answer to my problem is to (somehow) use tunefs to disable journaling and enable soft updates, however, I'm not sure how to do that.

I found the official documentation and it looked promising. However, I got stuck on the second step, umount /usr /var.

I haven't really messed with mounting/unmounting stuff in the past. Why is the documentation unmounting /usr and /var? I installed FreeBSD with the guided partition option in the installer, using the default options.

Anyway, the immediate problem is that I want to use dump to make a system backup, but I can't because UFS+journaling can't use snapshots, which dump uses to create the backup of a live system.

Help would be greatly appreciated.

 

[azz_kikr]

You need to restart the system in single user mode, then tunefs -j disable /dev/blablab. Create the dump and then re-enable it.

If you don't want to take the system down, take a look at rsync/tar/... because dump isn't going to work. It's either journalling or dump on live systems. Or switch to ZFS, which has working snapshots.

 

[Anonymous]

... umount /usr /var.

... Why is the documentation unmounting /usr and /var? I installed FreeBSD with the guided partition option in the installer, using the default options.

In the past (before FreeBSD 9.x) the default scheme created separate partitions/slices for /, /usr, /var, /tmp and swap. Nowadays, the default partition scheme is / and swap. So, if you stayed with the default option, your system does not have separate volumes for /usr and /var that could be unmounted.

Anyway, the immediate problem is that I want to use dump to make a system backup, but I can't because UFS+journaling can't use snapshots, which dump uses to create the backup of a live system.

You need to boot your machine from another disk - perhaps a Live CD or a pen drive. Then you would use tunefs for making changes to your non-mounted target volume.

 

[wblock@]

I wanted to practice backing up and restoring a system running FreeBSD 9.1, but I ran into a problem when I tried to use dump.

Snapshots are not yet supported when running with journaled soft updates.

I found this post, which was a little helpful. I understand that the answer to my problem is to (somehow) use tunefs to disable journaling and enable soft updates, however, I'm not sure how to do that.

Print out /etc/fstab. Boot and choose Single User Mode from the menu. Use tunefs -j disable on each of the UFS filesystems shown in /etc/fstab:

# tunefs -j disable /dev/ada0p2
# tunefs -j disable /dev/ada0p3
...

I found the official documentation and it looked promising. However, I got stuck on the second step, umount /usr /var.

That is the documentation for gjournal(8), not the same thing as SUJ.

I haven't really messed with mounting/unmounting stuff in the past. Why is the documentation unmounting /usr and /var?

Because filesystem properties can't be modified when the filesystem is in use.

 

[jalla]

Note that you don't have to turn off journaling to perform dumps. You can dump the live filesystems by dropping the '-L' option.

 

[npgm]

In the past (before FreeBSD 9.x) the default scheme created separate partitions/slices for /, /usr, /var, /tmp and swap. Nowadays, the default partition scheme is / and swap. So, if you stayed with the default option, your system does not have separate volumes for /usr and /var that could be unmounted.

Oh, thanks! The old documentation threw me off. This totally makes sense now.

Note that you don't have to turn off journaling to perform dumps. You can dump the live filesystems by dropping the '-L' option.

Oh. This seems like the easier option. What happens if I drop the -L option? The reason for the snapshot, I thought, was to dump a static image of the filesystem. Could this possibly cause problems, like corruption or something, for my backups?

 

[wblock@]

Note that you don't have to turn off journaling to perform dumps. You can dump the live filesystems by dropping the '-L' option.

-L makes a snapshot, but does not get around the problems with SUJ. I've managed to dump(8) small filesystems that are running SUJ, but anything nontrivial will produce that message in the first post. Or rather, that's what happened the last time I tried it, and the message is still in sys/ufs/ffs/ffs_snapshot.c.

 

[jalla]

-L makes a snapshot, but does not get around the problems with SUJ. I've managed to dump(8) small filesystems that are running SUJ, but anything nontrivial will produce that message in the first post. Or rather, that's what happened the last time I tried it, and the message is still in sys/ufs/ffs/ffs_snapshot.c.

I don't seem to have any problem with it

stingray:/d/dumps# tunefs -j enable /dev/ada0s2f
Using inode 4 in cg 0 for 33554432 byte journal
tunefs: soft updates journaling set

stingray:/d/dumps# mount /dev/ada0s2f /mnt

stingray:/d/dumps# df -h /mnt
Filesystem      Size    Used   Avail Capacity  Mounted on
/dev/ada0s2f     19G    7.7G     10G    42%    /mnt

stingray:/d/dumps# dump -0af sujtest /dev/ada0s2f
  DUMP: WARNING: should use -L when dumping live read-write filesystems!
  DUMP: Date of this level 0 dump: Fri Aug 23 10:18:03 2013
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/ada0s2f to sujtest
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 7252859 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 37.07% done, finished in 0:08 at Fri Aug 23 10:31:36 2013
  DUMP: 78.08% done, finished in 0:02 at Fri Aug 23 10:30:55 2013
  DUMP: DUMP: 7263433 tape blocks on 1 volume
  DUMP: finished in 751 seconds, throughput 9671 KBytes/sec
  DUMP: Closing sujtest
  DUMP: DUMP IS DONE

 

[jalla]

Oh, thanks! The old documentation threw me off. This totally makes sense now.


Oh. This seems like the easier option. What happens if I drop the -L option? The reason for the snapshot, I thought, was to dump a static image of the filesystem. Could this possibly cause problems, like corruption or something, for my backups?

I don't think the risk of a corrupt backup is very high. Remember that dumping live filesystems was the standard procedure for the 20 years or so before snapshots were even possible in UFS.

 

[jstarcher]

I'm not sure I'd recommend doing live dumps without the -L option. While I can confirm that the dump of a SU+J filesystem using dump without the -L does work, I got some scary errors while running restore (FreeBSD 9.1).

I think it's okay in my situation as I pull database backups manually anyway, however, I would be very careful about relying on live dumps when not using the -L option. There is certainly a lot of room for missing data and/or corruption it seems to me.

 

[frabron]

I'm in the same boat here. I've got journaling turned on for my filesystems, but I'd also like to use dump for making backups. Now I'm hesitant if journaling is maybe worth more than using dump, but my experience in server administration is too little to figure that out. Maybe someone with more insight can put in some opinion if it is worth to disable journaling in favor of the ability to use dump.

Frank

 

[kpa]

Journaling saves some time in case of a crash because the full fsck(8) can be then skipped. However on a server I would never skip the full fsck(8) in case the server has crashed so journaling doesn't have much use in that environment in my opinion.

 

[wblock@]

Remember that SUJ does not protect data, it protects the integrity of the filesystem structures, and the main benefit is a shorter boot time after a crash. As to whether or not to use it, it depends on whether you have large UFS filesystems and frequent crashes or power failures that aren't prevented by a UPS. If the system does crash unexpectedly, can you afford it being down for as long as a full fsck(8) takes?

I don't use SUJ. My main drives are SSDs which can do a fsck very quickly anyway, and my largest UFS data drives are 1 TB and only take a few minutes. Larger filesystems are on ZFS, which is journaled and does not have a fsck (unless you count zpool scrub, which I do, but that runs in the background and not at startup).

 

[frabron]

Well, that makes a decision easier, thanks folks. I was already quite biased towards dump over SUJ, and now I'm confident that I can turn it off and use dump without any worries