When working with legacy systems, we often encounter ext4 partitions without LVM configuration. Unlike LVM snapshots which provide atomic point-in-time copies, raw ext4 partitions require alternative approaches for live backup operations. The key constraints are:

• Must maintain filesystem consistency
• Cannot unmount the root partition
• Should minimize performance impact
• Need to preserve all metadata and hard links

The e2image utility is specifically designed for this scenario. It can create consistent snapshots of mounted ext4 filesystems by:

# Basic live backup command
sudo e2image -ra /dev/sda1 /backup/sda1.backup

# With progress monitoring
sudo e2image -rap /dev/sda1 /backup/sda1.backup | pv -petr > /dev/null

For more control over the backup process, combine fsfreeze with dd:

# Freeze the filesystem
sudo fsfreeze -f /mnt/root

# Create block-level backup
sudo dd if=/dev/sda1 of=/backup/sda1.dd bs=4M status=progress

# Unfreeze
sudo fsfreeze -u /mnt/root

Always verify backups before considering them reliable:

# Check backup integrity
sudo e2fsck -f /backup/sda1.backup

# For dd images, mount and verify
sudo mount -o loop /backup/sda1.dd /mnt/backup_check
ls -la /mnt/backup_check
sudo umount /mnt/backup_check

When running these operations on production systems:

• Schedule during low-usage periods
• Monitor system load with vmstat 1
• Consider using ionice to reduce I/O priority
• For large partitions, pipe output through compression

# Low-impact compressed backup example
sudo e2image -ra /dev/sda1 - | pigz -6 > /backup/sda1.backup.gz

Create a cron job for periodic snapshots:

# /etc/cron.daily/ext4-backup
#!/bin/bash
BACKUP_DIR="/backup/$(date +%Y%m%d)"
mkdir -p "$BACKUP_DIR"
e2image -rap /dev/sda1 "$BACKUP_DIR/rootfs.backup"
find /backup -type d -mtime +7 -exec rm -rf {} \;

When dealing with production servers, taking filesystem snapshots without LVM presents unique challenges. The primary concerns are:

• Maintaining filesystem consistency during backup
• Minimizing performance impact on running services
• Ensuring all files (including open ones) are properly captured

Here are three reliable methods I've used in production environments:

Method 1: Using e2image for Consistent Snapshots

The e2image tool is part of e2fsprogs and provides a low-level way to clone ext4 partitions:

# Create a raw image of the partition
e2image -rap /dev/sda1 /backup/sda1.img

# For incremental backups (requires kernel 4.0+)
e2image -rap -I /dev/sda1 /backup/sda1-incremental.img

Method 2: Block-Level Copy with dd and sync

For complete partition backups, this approach works well:

# Create a temporary snapshot device
losetup -f /backup/snapshot.img
losetup /dev/loop0 /backup/snapshot.img

# Perform the actual copy
dd if=/dev/sda1 of=/dev/loop0 bs=1M status=progress &
sync
wait

Method 3: Filesystem-Freeze Approach

For critical systems where absolute consistency is required:

# Freeze the filesystem
fsfreeze --freeze /mnt/root

# Perform backup operation (using your preferred method)
rsync -aHAX --delete /mnt/root/ /backup/server-root/

# Unfreeze the filesystem
fsfreeze --unfreeze /mnt/root

For services like MySQL or PostgreSQL running on the partition:

# MySQL example
mysql -e "FLUSH TABLES WITH READ LOCK; SYSTEM e2image -rap /dev/sda1 /backup/sda1.img; UNLOCK TABLES;"

When you need to restore from your backup:

# For raw image files
dd if=/backup/sda1.img of=/dev/sda1 bs=1M status=progress
e2fsck -f /dev/sda1
resize2fs /dev/sda1