Ran fsarchiver on the device, and it only backed up the main volume, (none of the subvolumes). I would consider this very basic functionality.

Hi,
first, thanks for your great app!

I'm learning fsarchiver within SystemRescue CD. It uses Arch Linux (Bash terminal).

I'm in a trouble with the --exclude filter to work.
My command is:
fsarchiver savefs -o "/path/191120.fsa" /dev/sda2 /dev/sda3 -v -j2 -Z9 --exclude="/cache2/entries/*" --exclude="/var/cache/pacman/pkg/*" --exclude="/baloo/*"

The first exclude filter
"/cache2/entries/*" doesn't seem to work (it is the firefox cache in ./.cache/mozilla/firefox/3fw5bqse.default-esr/cache2/entries/).
I'd like to exclude every files in the 'entries' directory.
The others --exclude filters seem ok.

The first question: I have to put the absolute path? I wouldn't use the absolute path, because the firefox number in the profile change at every system.
The fsarchiver help shows:

• save a filesystem and exclude all files/dirs called 'pagefile.':
  fsarchiver savefs /data/myarchive.fsa /dev/sda1 --exclude='pagefile.'
• generic exclude for 'share' such as '/usr/share' and '/usr/local/share':
  fsarchiver savefs /data/myarchive.fsa --exclude=share
• absolute exclude valid for '/usr/share' but not for '/usr/local/share':
  fsarchiver savefs /data/myarchive.fsa --exclude=/usr/share

The second question: How can I check which files are put from fsarchiver in the archive?

The third question: I tried to redirect the fsarchiver archinfo output to a file with:
fsarchiver archinfo /path/191120.fsa | tee /mnt/bk-data/Backups/fsarchiver/fsa.log or
fsarchiver archinfo /path/191120.fsa >> /mnt/bk-data/Backups/fsarchiver/fsa.log
fsarchiver archinfo /path/191120.fsa 1>> /mnt/bk-data/Backups/fsarchiver/fsa.log
but it doesn't work. The file log is empty.
In Terminal is ok.

Any ideas? Thanks in advance.

Ubuntu 20.04
fsarchiver 30c9e23

FAT32 file-system archived with fsarchiver 0.8.6-git (20191230):

# fsarchiver -V
fsarchiver 0.8.6-git (20191230)
# fsarchiver archinfo Efi-FAT32.fsa
====================== archive information ======================
Archive type: 			filesystems
Filesystems count: 		1
Archive id: 			5e6f60dc
Archive file format: 		FsArCh_002
Archive created with: 		0.8.6-git
archreader.c#329,archreader_read_header(): archive-id in header does not match: archid=[5e6f6a3e], expected=[5e6f60dc]
Archive creation date: 		2020-03-11_21-57-47
Archive label: 			<none>
Minimum fsarchiver version:	0.6.4.0
Compression level: 		11 (zstd level 11)
Encryption algorithm: 		none

===================== filesystem information ====================
Filesystem id in archive: 	0
Filesystem format: 		vfat
Filesystem label: 		FAT32 
Filesystem uuid: 		7916B3CB
Original device: 		/dev/sdc1
Original filesystem size: 	510.98 MB (535801856 bytes)
Space used in filesystem: 	14.15 MB (14839808 bytes)

No such issue with Ext4 file-system archived with fsarchiver 0.8.6-git (20191230):

# fsarchiver -V
fsarchiver 0.8.6-git (20191230)
# fsarchiver archinfo Ext4.fsa
====================== archive information ======================
Archive type: 			filesystems
Filesystems count: 		1
Archive id: 			5e6ed95c
Archive file format: 		FsArCh_002
Archive created with: 		0.8.6-git
Archive creation date: 		2020-03-11_21-57-48
Archive label: 			<none>
Minimum fsarchiver version:	0.6.4.0
Compression level: 		11 (zstd level 11)
Encryption algorithm: 		none

===================== filesystem information ====================
Filesystem id in archive: 	0
Filesystem format: 		ext4
Filesystem label: 		Ext4
Filesystem uuid: 		30c45b81-890d-47ac-85c1-971537b7bae5
Original device: 		/dev/sdc3
Original filesystem size: 	97.93 GB (105152544768 bytes)
Space used in filesystem: 	34.60 GB (37155958784 bytes)

No such issue with FAT32 file-system archived with fsarchiver 0.8.6-git --1 year ago--:

# fsarchiver archinfo Efi-FAT32-old.fsa
====================== archive information ======================
Archive type: 			filesystems
Filesystems count: 		1
Archive id: 			5c9eabdc
Archive file format: 		FsArCh_002
Archive created with: 		0.8.6-git
Archive creation date: 		2019-03-21_17-28-28
Archive label: 			<none>
Minimum fsarchiver version:	0.6.4.0
Compression level: 		21 (zstd level 21)
Encryption algorithm: 		none

===================== filesystem information ====================
Filesystem id in archive: 	0
Filesystem format: 		vfat
Filesystem label: 		FAT32
Filesystem uuid: 		7916B3CB
Original device: 		/dev/sdb1
Original filesystem size: 	510.98 MB (535805952 bytes)
Space used in filesystem: 	7.74 MB (8114176 bytes)

The archives are created with the command:

fsarchiver -j $cpu_threads -v -o -A -Z 11 savefs <filename>.fsa /dev/<sdxn>

I'm positive no archive can be corrupted as they are checked regularly.

This issue is most probably linked to this unsolved one.

Something have probably been changed in the code between 2019-03-21 and 2019-12-30 in the way the FAT32 file-systems are handled.

what hapenned :
Restoring a backup make with lz4 compression with an older release fail in a non intuitive way. It will simply stall indefinitely, with no error message, and require to kill the program.

how to reproduce :

1. get a compiled static binary from fsarchiver version 0.8.3 or later from the website.
2. use savefs to make a backup of the file system
3. on a new system, use an older version of fsarchiver. Used an older System Rescue CD here.
4. try to restore the file system. the restore stall and nothing is printed on the console. you cannot do control-C to cancel it. sending kill signal does nothing. you need to kill -9.
5. try again with -v one time. you see that it can format the file system, and create some folder, but will stall on the first file. There is no error message.
6. try again with -V 2 times. It will print more information including this line at the top

thread_comp.c#243,decompress_block_generic(): unsupported compression algorithm: 7

comment :
Here, clearly, the user is at fault. fsarchiver 0.8.3 will default to the new algorithm and this conflicted with the older program but it's still a user fault. they (I) just need to use the newer version to do the restore.

I don't ask to patch all older version of the program, that's impossible.
However, if you could modify the current version of the program to handle this case more gracefully, that would be great.
If in the future a new compression is added, this issue would be more clear than what is currently is.

possible improvement could be :
if there is an error when uncompressing a file,

1. print an error message that will appear without needing to add -vv.
2. get a more descriptive error message. for example "Restore failed because the file was saved with an unknown compression algorithm".
3. stop the restore and exit the program.

if that's not possible, it's not that big of a deal. you don't add new compression algorithm quite often hehe.

I don't have the room to just restore the archive...Is there a way to mount the fsa file like any other partition image file, please?

Hi, I put a patch on the results of testing your application via cppcheck

cppcheck.patch.txt

NO NAME (plus four spaces) means no label AFAIK.

https://github.com/dosfstools/dosfstools/blob/master/src/mkfs.fat.c#L80
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/libblkid/src/superblocks/vfat.c#n114

# fsarchiver archinfo vfat-no-label.fsa 
====================== archive information ======================
Archive type:           filesystems
Filesystems count:      1
Archive id:             57af91b4
Archive file format:        FsArCh_002
Archive created with:       0.8.0-git
Archive creation date:      2016-08-09_17-15-03
Archive label:          <none>
Minimum fsarchiver version: 0.6.4.0
Compression level:      3 (gzip level 6)
Encryption algorithm:       none

===================== filesystem information ====================
Filesystem id in archive:   0
Filesystem format:      vfat
Filesystem label:       NO NAME    
Filesystem uuid:        <none>
Original device:        /dev/sda2
Original filesystem size:   116.41 GB (124998680576 bytes)
Space used in filesystem:   64.00 KB (65536 bytes)

# fsarchiver -vv restfs vfat-no-label.fsa id=0,dest=/dev/sda2
Detected fileformat=2 in archive /home/marcos/ztest/vfat-no-label.fsa
Current fsarchiver version: 0.8.0.0
Minimum fsarchiver version for that archive: 0.6.4.0
============= extracting filesystem 0 =============
Current fsarchiver version: 0.8.0.0
Minimum fsarchiver version for that filesystem: 0.8.0.0
End of volume [/home/marcos/ztest/vfat-no-label.fsa]
strdico_get_string(dicocmdline, 'mkfsopt') doesn't exist
strdico_get_string(dicocmdline, 'label') doesn't exist
strdico_get_string(dicocmdline, 'uuid') doesn't exist
filesystem_type=[vfat]
filesystem_mkfsoptions=[]
filesystem_mkfslabel=[]
filesystem_mkfsuuid=[]
filesystem_space_total=[116.41 GB]
filesystem_space_used=[64.00 KB]
getpathtoprog(mkfs.vfat)=[/sbin/mkfs.vfat]
executing [mkfs.vfat --help]...
command [mkfs.vfat --help] returned 0
getpathtoprog(mkfs.vfat)=[/sbin/mkfs.vfat]
executing [mkfs.vfat  -F 32  -n 'NO NAME    '  -i '996450C1'  /dev/sda2]...
command [mkfs.vfat  -F 32  -n 'NO NAME    '  -i '996450C1'  /dev/sda2] returned 0
Mount information: []
partition [/dev/sda2] was successfully mounted on [/tmp/fsa/20160809-171958-000651fa-00] as [vfat] with options []
-[00][ 49%][DIR     ] /
-[00][100%][REGFILEM] /aaa.txt
Statistics for filesystem 0
* files successfully processed:....regfiles=1, directories=1, symlinks=0, hardlinks=0, specials=0
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0

# blkid -s LABEL /dev/sda2    # empty
#

Then -n 'NO NAME ' in mkfs.vfat is redundant (does not hurt though).

Todays backup of a 30G Linux partition with ~15G of data took several hours (actually, I aborted it after several hours). In the past, this process has been rather quick (matter of minutes).

Running fsarchiver -v shows the following:

            xattr:file=[/var/log/lastlog], attrid=0, name=[security.selinux], size=37
            xattr:lgetxattr(/var/log/lastlog,security.selinux)=37
            xattr:lgetxattr(/var/log/lastlog,security.selinux)=37: [security.selinux]
-[00][ 83%][REGFILE ] /var/log/lastlog
oper_save.c#171,createar_obj_regfile_unique(): backup_obj_regfile_unique(file=/var/log/lastlog, size=1168000000292)

/var/log/lastlog is so-called a sparse file, its actual size is

$ du -hs /tmp/fsa/20190123-191847-0001b2f9-00/var/log/lastlog 
292K	/tmp/fsa/20190123-191847-0001b2f9-00/var/log/lastlog

$ stat /tmp/fsa/20190123-191847-0001b2f9-00/var/log/lastlog 
  File: /tmp/fsa/20190123-191847-0001b2f9-00/var/log/lastlog
  Size: 1168000000292	Blocks: 584        IO Block: 4096   regular file
Device: 806h/2054d	Inode: 145655      Links: 1
Access: (0664/-rw-rw-r--)  Uid: (    0/    root)   Gid: (   43/    utmp)
Access: 2019-01-22 19:40:36.006267137 +0100
Modify: 2019-01-22 19:40:36.006267137 +0100
Change: 2019-01-22 19:40:36.006267137 +0100
 Birth: -

Looks like fsarchiver tries to process 1TB of data.

https://linux.die.net/man/8/lastlog

Here is the log:

[root@localhost ~]# yum install zlib-devel bzip2-devel lzo-devel lz4-devel xz-devel e2fsprogs-devel libgcrypt-devel libattr-devel libblkid-devel
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.sonic.net
 * extras: centos.gbeservers.com
 * updates: mirror.chpc.utah.edu
Resolving Dependencies
--> Running transaction check
...
...
Installed:
  bzip2-devel.x86_64 0:1.0.6-13.el7         e2fsprogs-devel.x86_64 0:1.42.9-12.el7_5     libattr-devel.x86_64 0:2.4.46-13.el7
  libblkid-devel.x86_64 0:2.23.2-52.el7     libgcrypt-devel.x86_64 0:1.5.3-14.el7        lz4-devel.x86_64 0:1.7.5-2.el7
  lzo-devel.x86_64 0:2.06-8.el7             xz-devel.x86_64 0:5.2.2-1.el7                zlib-devel.x86_64 0:1.2.7-17.el7

Dependency Installed:
  libcom_err-devel.x86_64 0:1.42.9-12.el7_5     libgpg-error-devel.x86_64 0:1.12-3.el7     libuuid-devel.x86_64 0:2.23.2-52.el7
  lzo-minilzo.x86_64 0:2.06-8.el7

Complete!

[root@localhost ~]# yum install fsarchiver-0.8.4-1.el7.x86_64.rpm
Loaded plugins: fastestmirror
Examining fsarchiver-0.8.4-1.el7.x86_64.rpm: fsarchiver-0.8.4-1.el7.x86_64
Marking fsarchiver-0.8.4-1.el7.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package fsarchiver.x86_64 0:0.8.4-1.el7 will be installed
--> Processing Dependency: libzstd.so.1()(64bit) for package: fsarchiver-0.8.4-1.el7.x86_64
Loading mirror speeds from cached hostfile
 * base: mirrors.sonic.net
 * extras: centos.gbeservers.com
 * updates: mirror.chpc.utah.edu
--> Finished Dependency Resolution
Error: Package: fsarchiver-0.8.4-1.el7.x86_64 (/fsarchiver-0.8.4-1.el7.x86_64)
           Requires: libzstd.so.1()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

I use 0.8.5 (2018-07-10) version.
I want to keep inodes size of partition.
I try this command, but dont' effective.
Added mkfsopt="-O ^resize_inode" params.

[root@sysresccd ~]# fsarchiver restfs -vj8z0 file.fsa id=0,dest=/dev/sdb1,label=aaaaa,mkfsopt="-O ^resize_inode"
============= extracting filesystem 0 =============
executing [mke2fs -V]...
command [mke2fs -V] returned 0
executing [mke2fs -V]...
command [mke2fs -V] returned 0
executing [mke2fs /dev/sdb1  -q  -F  -O ^resize_inode  -b 4096  -L 'aaaaa'  -U 47849ac4-0cba-4fde-b7f0-0c22b159ad13  -I 256  -r 1  -O has_journal,ext_attr,resize_inode,dir_index,^sparse_super2,filetype,extent,^journal_dev,flex_bg,^meta_bg,^mmp,64bit,^inline_data,^ea_inode,^large_dir,large_file,huge_file,sparse_super,^uninit_bg,dir_nlink,extra_isize,^bigalloc,metadata_csum,^project ]...
command [mke2fs /dev/sdb1  -q  -F  -O ^resize_inode  -b 4096  -L 'aaaaa'  -U 47849ac4-0cba-4fde-b7f0-0c22b159ad13  -I 256  -r 1  -O has_journal,ext_attr,resize_inode,dir_index,^sparse_super2,filetype,extent,^journal_dev,flex_bg,^meta_bg,^mmp,64bit,^inline_data,^ea_inode,^large_dir,large_file,huge_file,sparse_super,^uninit_bg,dir_nlink,extra_isize,^bigalloc,metadata_csum,^project ] returned 0
executing [tune2fs /dev/sdb1  -o user_xattr,acl  -c 0  -i 0d ]...
command [tune2fs /dev/sdb1  -o user_xattr,acl  -c 0  -i 0d ] returned 0
Mount information: []
-[00][ 24%][DIR     ] /
-[00][ 49%][DIR     ] /lost+found
-[00][ 74%][DIR     ] /aaa
-[00][100%][REGFILEM] /file
Statistics for filesystem 0
* files successfully processed:....regfiles=1, directories=3, symlinks=0, hardlinks=0, specials=0
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0

I find this line of codes:

XFSv5 filesystems have their UUID stamped on every metadata block and cannot have it changed by xfs_admin until xfsprogs 4.2.0 and kernel 4.3 (when sb_meta_uuid was added). Once configured, it will set an incompatible superblock flag to prevent older kernels from mounting the fs.

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=commit;h=609f6bb20b7972c1a68370faea1dcbcf39912e07

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=commit;h=9c4e12fb60c15dc9c5e54041c9679454b42cb23e
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ce748eaa65f2e9392ba82726503c8d994ffd6393

If mkfs.xfs had an option to define UUID at filesystem creation it would solve the problem. With the advantage of keeping both UUIDs, internal and "visible", in sync (no incompat flag) and, thus, preserving compatibility with older kernels, 3.15+ (-m crc=1,finobt=0) or 3.16+ (-m crc=1,finobt=1). Such an option does exist (-m uuid=<UUID>). Unfortunately it was only added in mkfs.xfs 4.3.0.

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=commit;h=6af48b97f8ef7196e1303996995b3614dde24ec2

Is an option for FSArchiver require mkfs.xfs >= 4.3.0 when restoring XFSv5 fs?

OS: Lubuntu 18.04
64 bit

fsarchiver installed through aptitude

fsarchiver --version
fsarchiver 0.8.4 (2018-02-19)

Downloaded the newest version from github allso same error code

fsarchiver-static-0.8.5.x86_64

The btrfs was created with

mkfs.btrfs -L "NAME" /dev/sdb1

Backed up with

fsarchiver -j8 -Z 22 -c - savefs "/dest/to/fsarchiver.fsa" /dev/sdb1

Fails With

fsarchiver -c - restfs "/dest/to/fsarchiver.fsa" id=0,dest=/dev/sdb1
Enter password: 
fs_btrfs.c#106,btrfs_mkfs(): command [mkfs.btrfs -f /dev/sdb1    -L 'BackUpAndSync'  -U '776fcda5-8162-4bd8-9d5f-dc6c54af67b1'  -s 4096 ] failed
oper_restore.c#1296,extractar_filesystem_extract(): cannot make filesystem btrfs on partition /dev/sdb1

Hi, I continue view your code using cppcheck, this is the place in doubt - it will never be fulfilled:

file archwriter.c:
line 193:
"
if (wb->size <=0)
{ errprintf("wb->size=%ld\n", (long)wb->size);
return -1;
}
"
wb->size - is unsigned value (u64), and it will never be less than 0.

There's something wrong

Hi,
I'm using fsarchiver over systemrescuecd-7.0.0 and when I try to restore the backup (also made with systemrescuecd-7.0.0 but on another machine), it gives me an error at the moment of format the partition:

# fsarchiver restfs backup-2.fsa id=0,dest=/dev/nvme0n1p2 -j4 -v
============= extracting filesystem 0 =============
executing [mke2fs -V]...
command [mke2fs -V] returned 0
executing [mke2fs -V]...
command [mke2fs -V] returned 0
executing [mke2fs /dev/nvme0n1p2  -q  -F    -b 4096  -U 9423c6d9-f44b-434e-a1cf-7d976c590d88  -I 256  -r 1  -O has_journal,ext_attr,resize_inode,dir_index,^sparse_super2,filetype,extent,^journal_dev,flex_bg,^meta_bg,^mmp,^64bit,^inline_data,^ea_inode,^large_dir,large_file,huge_file,sparse_super,uninit_bg,dir_nlink,extra_isize,^bigalloc,^metadata_csum,^project ]...
command [mke2fs /dev/nvme0n1p2  -q  -F    -b 4096  -U 9423c6d9-f44b-434e-a1cf-7d976c590d88  -I 256  -r 1  -O has_journal,ext_attr,resize_inode,dir_index,^sparse_super2,filetype,extent,^journal_dev,flex_bg,^meta_bg,^mmp,^64bit,^inline_data,^ea_inode,^large_dir,large_file,huge_file,sparse_super,uninit_bg,dir_nlink,extra_isize,^bigalloc,^metadata_csum,^project ] returned 1
fs_ext2.c#373,extfs_mkfs(): command [mke2fs /dev/nvme0n1p2  -q  -F    -b 4096  -U 9423c6d9-f44b-434e-a1cf-7d976c590d88  -I 256  -r 1  -O has_journal,ext_attr,resize_inode,dir_index,^sparse_super2,filetype,extent,^journal_dev,flex_bg,^meta_bg,^mmp,^64bit,^inline_data,^ea_inode,^large_dir,large_file,huge_file,sparse_super,uninit_bg,dir_nlink,extra_isize,^bigalloc,^metadata_csum,^project ] failed with return status=1
oper_restore.c#1296,extractar_filesystem_extract(): cannot make filesystem ext4 on partition /dev/nvme0n1p2

Detailed output of mke2fs:

# mke2fs -vvvv /dev/nvme0n1p2   -F    -b 4096  -U 9423c6d9-f44b-434e-a1cf-7d976c590d88  -I 256  -r 1  -O has_journal,ext_attr,resize_inode,dir_index,^sparse_super2,filetype,extent,^journal_dev,flex_bg,^meta_bg,^mmp,^64bit,^inline_data,^ea_inode,^large_dir,large_file,huge_file,sparse_super,uninit_bg,dir_nlink,extra_isize,^bigalloc,^metadata_csum,^project
mke2fs 1.45.6 (20-Mar-2020)
fs_types for mke2fs.conf resolution: 'ext2'
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1648320 inodes, 6591744 blocks
329587 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
202 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Filesystem UUID: 9423c6d9-f44b-434e-a1cf-7d976c590d88
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
	4096000

Allocating group tables: done
Writing inode tables: done
ext2fs_update_bb_inode: Cannot iterate data blocks of an inode containing inline data while setting bad block inode

But if I do an mkfs.ext4, it works correctly:

# mkfs.ext4 -vvvv /dev/nvme0n1p2
mke2fs 1.45.6 (20-Mar-2020)
fs_types for mke2fs.conf resolution: 'ext4'
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1648320 inodes, 6591744 blocks
329587 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2155872256
202 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Filesystem UUID: ea85265c-f912-4acd-b89b-5af57eff4c1e
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
	4096000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Anyone can tell me if I am doing anything wrong or if I can try something?

Thanks

FSArchiver is now available in Guix.
Please mention Guix in the home-page.
Also, please consider using the term GNU/Linux instead of just Linux.

I just discover that good project.
I was using tar | pv | xz > file, but your solution is more flexible.
Problem is that, it seems not possible to print a progress bar and remaining time, which pv does.
fsarchiver -v is ok for seeing "%", but as i want to compress xz-9 a heavy FS, remaining time is important to me (~ 3h).

fsarchiver 0.6.19 (2014-03-01)

The man page says : By default fsarchiver fails with an error if the partition if mounted

That should be "is" not "if"

Looking at your excellent tool, I have a bit of a question / request about restores.

I have some servers that are remote and so backing up is fine, but what if I want to restore. I can't go to the server to plug in a USB stick to do an OS partition restore. On Windows, this is easy to do (various tools like Macrium Reflect make this super easy as they install an alternative boot loader, and load into that and then perform the restore, then reboot back into the restored OS) but I'm desperately looking for a tool that will allow me to do the same on Linux.

• Can your tool do this?

• Might there be a project that offers functionality like this that you know of (i.e. reboot into an alternative OS, run a task, then reboot back into the main OS)?

• Might this be something that you could consider on a future version of the tool?

I know this might be complex, but it would really be an amazing feature that that could be really worth (the ability to remotely restore a bare metal server back to a known backup as easily as a rolling back a VM would be so useful!).

Hi,

Right now, the only way to validate that an archive is not corrupt is to try to restore it. It would be much better to have an option that would scan the file and validate the checksums without trying to restore the files. For archives that have been copied to different media or are going to be stored for a while before restoring, this would be a very handy option.

Thanks

Regards

Do not force the compression of archived files, as some people often manually compress them afterhand using standalone utilities like lrzip or zpaq. If you compress them beforehand it interferes with those better compression utilities.

Trying to restore to disk archive of an ext4 partition.

$ fsarchiver archinfo /mnt/arch/data_disk.fsa
====================== archive information ======================
Archive type: filesystems
Filesystems count: 1
Archive id: 5717ccbf
Archive file format: FsArCh_002
Archive created with: 0.6.22
Archive creation date: 2016-04-24_12-02-41
Archive label:
Minimum fsarchiver version: 0.6.4.0
Compression level: 3 (gzip level 6)
Encryption algorithm: none
===================== filesystem information ====================
Filesystem id in archive: 0
Filesystem format: ext4
Filesystem label:
Filesystem uuid: c4a08c0a-15e9-4bdf-92fe-e2c69c482426
Original device: /dev/sdb
Original filesystem size: 2.46 TB (2705512898560 bytes)
Space used in filesystem: 356.26 GB (382531969024 bytes)

But get an error cannot format the filesystem ext4 on partition.

$ sudo fsarchiver -v restfs /mnt/arch/data_disk.fsa id=0,dest=/dev/sdc
============= extracting filesystem 0 =============
executing [mke2fs -V]...
command [mke2fs -V] returned 0
executing [mke2fs -V]...
command [mke2fs -V] returned 0
executing [mke2fs /dev/sdc -q -r 1 -b 4096 -I 256 -O has_journal,ext_attr,resize_inode,dir_index,filetype
,extent,^journal_dev,flex_bg,^meta_bg,large_file,huge_file,sparse_super,uninit_bg,dir_nlink,extra_isize -E stride=1 ]...
command [mke2fs /dev/sdc -q -r 1 -b 4096 -I 256 -O has_journal,ext_attr,resize_inode,dir_index,filetype,extent,^journal_dev,flex_bg,^meta_bg,large_file,huge_file,sparse_super,uninit_bg,dir_nlink,extra_isize -E stride=1 ] returned 1
fs_ext2.c#281,extfs_mkfs(): command [mke2fs /dev/sdc -q -r 1 -b 4096 -I 256 -O has_journal,ext_attr,resize_inode,dir_index,filetype,extent,^journal_dev,flex_bg,^meta_bg,large_file,huge_file,sparse_super,uninit_bg,dir_nlink,extra_isize -E stride=1 ] failed with return status=1
oper_restore.c#1281,extractar_filesystem_extract(): cannot format the filesystem ext4 on partition /dev/sdc

I want to use fsarchiver in my OS deploy project with bt sequential transfert to not store temp file on the destination.
Is there any way to add a pipable option ? as wimlib does
https://wimlib.net/apidoc/group__G__writing__and__overwriting__wims.html#ga5e1c08e0079e90a1a7212815c749892e

mkfs.xfs upstream support for -i sparse exists since xfsprogs 4.2.0 (and fsarchiver follows it). Unfortunately RHEL/CentOS 7.3 changed its mkfs.xfs 4.5.0 to remove the option:

https://git.centos.org/blob/rpms!xfsprogs.git/4a5a342863508da76775a9477cea1d68fab98a67/SOURCES!xfsprogs-4.5.0-change-mkfs-options.patch

So, when running under RHEL 7.3, fsarchiver fails with:

# fsarchiver restfs rhel-test.fsa id=0,dest=/dev/sdb
fs_xfs.c#243,xfs_mkfs(): command [mkfs.xfs -f /dev/sdb    -b size=4096  -m crc=1  -m finobt=0  -m uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  -i sparse=0 ] failed
oper_restore.c#1295,extractar_filesystem_extract(): cannot make filesystem xfs on partition /dev/sdb

# mkfs.xfs -f /dev/sdb    -b size=4096  -m crc=1  -m finobt=0  -m uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  -i sparse=0
unknown option -i sparse=0
Usage: mkfs.xfs
/* blocksize */         [-b log=n|size=num]
/* metadata */          [-m crc=0|1,finobt=0|1,uuid=xxx]
/* data subvol */       [-d agcount=n,agsize=n,file,name=xxx,size=num,
                            (sunit=value,swidth=value|su=num,sw=num|noalign),
                            sectlog=n|sectsize=num
/* force overwrite */   [-f]
/* inode size */        [-i log=n|perblock=n|size=num,maxpct=n,attr=0|1|2,
                            projid32bit=0|1]
/* no discard */        [-K]
/* log subvol */        [-l agnum=n,internal,size=num,logdev=xxx,version=n
                            sunit=value|su=num,sectlog=n|sectsize=num,
                            lazy-count=0|1]
/* label */             [-L label (maximum 12 characters)]
/* naming */            [-n log=n|size=num,version=2|ci,ftype=0|1]
/* no-op info only */   [-N]
/* prototype file */    [-p fname]
/* quiet */             [-q]
/* realtime subvol */   [-r extsize=num,size=num,rtdev=xxx]
/* sectorsize */        [-s log=n|size=num]
/* version */           [-V]
                        devicename
<devicename> is required unless -d name=xxx is given.
<num> is xxx (bytes), xxxs (sectors), xxxb (fs blocks), xxxk (xxx KiB),
      xxxm (xxx MiB), xxxg (xxx GiB), xxxt (xxx TiB) or xxxp (xxx PiB).
<value> is xxx (512 byte blocks).

I cannot see a way to detect when we run the RHEL customized version. We probably need to bump minimum mkfs.xfs version to 4.8.0 for -i sparse. Since sparse=1 is considered stable in kernel 4.8+, let's assume folks will be running at least xfsprogs 4.8.0 when the feature gets widespread use. Or maybe only add the option when sparse=1?

Is there a way to extract just a single file or folder from an fs archive?

I've been running daily backups for months now and I simply want to restore a single accidentally deleted file from an archive. How can I do that?

I don't want to restore gigabytes of data and overwrite everything when I just need a single file.

Following one system restore, re-booted to find no menu, and a grub> prompt.
Boot-repair fixed it back to dual boot Ubuntu 15.10 systems.

Using two SSDs with a default install of primary system on first 128GB drive.
Second SSD 256GB gparted into two.
Installed Ubuntu 15.10 as maint system to first partition.
Second partition used for .fsa backups of primary system.
Used fsarchiver in maint system to archive primary system.
All worked fine, and dual boot still functional.
Used fsarchiver to restore primary system .fsa into maint system, intending to have two practically identical systems.
Booted to find no menu, and a grub> prompt.

Boot-repair fixed it back to dual boot Ubuntu 15.10 now practically identical systems.
So it all worked great, aside from the boot menu.

Hi,

according to http://forums.fsarchiver.org/viewtopic.php?f=14&t=1169, some forward error correction features were implemented to protect against archive corruption. Unfortunately, the code does not seem to be present in the last version.

Can you get the functionality back?

Thanks
Regards

mkfs.xfs 4.2.0 introduced sparse inode allocation feature [1]. Kernel support was added in 4.2 and is considered experimental up to current 4.7-rc.

Probably starting with kernel 4.8 [2], it will be fully supported. I guess they will wait a couple releases before enable it by default in mkfs.xfs.

From FSArchiver POV:

• Incompat flag is XFS_SB_FEAT_INCOMPAT_SPINODES
• mkfs.xfs (>= 4.2.0) option is "-i sparse=0|1"
• It depends on the V5 format

There is no hurry to implement this. While it is not enabled by default in mkfs.xfs, we are safe.

[1] Description in mkfs.xfs(8)

[2] http://article.gmane.org/gmane.comp.file-systems.xfs.general/76601
https://git.kernel.org/cgit/linux/kernel/git/dgc/linux-xfs.git/log/?h=xfs-4.8-misc-fixes-4

Using e2fsprogs 1.39 in CentOS 5.11:

fs_ext2.c: In function ‘extfs_mkfs’:
fs_ext2.c:276: error: ‘EXT4_FEATURE_INCOMPAT_FLEX_BG’ undeclared (first use in this function)
fs_ext2.c:276: error: (Each undeclared identifier is reported only once
fs_ext2.c:276: error: for each function it appears in.)
fs_ext2.c:278: error: ‘EXT4_FEATURE_RO_COMPAT_DIR_NLINK’ undeclared (first use in this function)
fs_ext2.c:278: error: ‘EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE’ undeclared (first use in this function)
fs_ext2.c:278: error: ‘EXT4_FEATURE_RO_COMPAT_GDT_CSUM’ undeclared (first use in this function)
fs_ext2.c:278: error: ‘EXT4_FEATURE_RO_COMPAT_HUGE_FILE’ undeclared (first use in this function)

• Since e2fsprogs 1.43, mke2fs enables by default the 64bit option. It was added around 1.40 (cannot find exactly when), but up to 1.41 it was buggy (http://marc.info/?l=linux-ext4&m=121607919430525&w=2). So -O 64bit was not recommended until 1.42 (http://marc.info/?l=linux-ext4&m=127652278706450&w=2), which also enabled the feature automatically if the filesystem being created was bigger than 16 TiB (auto_64-bit_support = 1 in /etc/mke2fs.conf). FSArchiver needs to respect this setting at restore now that is going to be used much more often on < 16 TiB volumes.

• Since kernel 3.5, EXT4 supports metadata checksumming (considered stable starting with 3.18^[1]), in a similar way as XFSv5. Userspace support exists since e2fsprogs 1.43 (-O metadata_csum).

When metadata_csum is enabled, changing UUID with tune2fs in a heavy populated fs is slow, as it needs to walk through filesystem metadata. This can be avoided using the -U <uuid> option introduced in mke2fs 1.41.4^[2] to set UUID at filesystem creation. FSArchiver is not affected by this problem, because it changes the UUID on fresh new empty fs, but -U <uuid> at mkfs time is more elegant though.

Superblock flags are:

EXT4_FEATURE_INCOMPAT_64BIT
EXT4_FEATURE_RO_COMPAT_METADATA_CSUM

^[1] https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=210baa5d8a58f84ab12772e80a839a4e74a54134
^[2] https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=b0afdda1bc044026336009576fbe6b72884140cb

Ubuntu 16.04 here.

Probably it will fail on Debian too for people with non-english locales.

On CentOS/Fedora/openSUSE I never run into this problem. Upstream xfsprogs only has polish and german translations. Debian/Ubuntu folks add more languages somehow (package language-pack-XX-base).

# fsarchiver -v restfs v5.fsa id=0,dest=/dev/sda2
============= extracting filesystem 0 =============
executing [mkfs.xfs -V]...
command [mkfs.xfs -V] returned 0
fs_xfs.c#96,xfs_mkfs(): Can't parse mkfs.xfs version number: x=y=0
oper_restore.c#1281,extractar_filesystem_extract(): cannot format the filesystem xfs on partition /dev/sda2

mkfs.xfs -V output does not match mkfs.xfs version X.Y.Z:
(pt_BR locale)

# mkfs.xfs -V
mkfs.xfs versão 4.3.0

Adding LANG=C makes it work:

# LANG=C mkfs.xfs -V
mkfs.xfs version 4.3.0

# LANG=C fsarchiver -v restfs v5.fsa id=0,dest=/dev/sda2
============= extracting filesystem 0 =============
executing [mkfs.xfs -V]...
command [mkfs.xfs -V] returned 0
executing [mkfs.xfs -f /dev/sda2    -b size=4096  -m crc=1  -m finobt=1  -m uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ]...
command [mkfs.xfs -f /dev/sda2    -b size=4096  -m crc=1  -m finobt=1  -m uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ] returned 0
Mount information: []
...

Hello.

I am trying to resize a Google Cloud disk to smaller, and think I should be able to accomplish using fsarchiver. Is it possible to run:

fsarchiver -A -a savefs /mnt/sdb/sda1.fsa /dev/sda1

Where sda1 is the source disk, and /mnt/sdb is a secondary disk attached to the instance. Mainly, can I save the fs (/dev/sda1) that is the primary/boot and mounted?

Finally I will attach a 3rd disk (/dev/sdc the final smaller disk) to the instance, and restore to it:

fsarchiver restfs /mnt/sdb/sda1.fsa id=0,dest=/dev/sdc

Will this process work?

Downloaded latest fsarchiver so I could get zstd compression on MX18 / Debian stable and converted/installed rpm to .deb with alien, fsarchiver is still complaining about missing libs

REF: https://www.fsarchiver.org/installation/

alien --to-deb fsarchiver-0.8.6-1.el7.x86_64.rpm

fsarchiver_0.8.6-2_amd64.deb generated

dpkg -i fsarchiver_0.8.6-2_amd64.deb

Unpacking fsarchiver (0.8.6-2) over (0.8.1-1)

fsarchiver: error while loading shared libraries: libgcrypt.so.11: cannot open shared object file: No such file or directory

apt install libzstd1 libzstd-dev zstd # apt install libcrypto++-dev libcrypto++-utils libgcrypt20-dev

whatprovides libgcrypt.so.11 ## apt-file search

Hit:1 http://security.debian.org stretch/updates InRelease
Hit:2 http://la.mxrepo.com/antix/stretch stretch InRelease
Hit:3 http://deb.debian.org/debian stretch-backports InRelease
Hit:4 http://mxrepo.com/mx/repo stretch InRelease
Hit:5 http://ftp.us.debian.org/debian stretch-updates InRelease
Hit:6 https://download.virtualbox.org/virtualbox/debian stretch InRelease
Ign:7 http://ftp.us.debian.org/debian stretch InRelease
Hit:8 http://ftp.us.debian.org/debian stretch Release
(no results)

mkfs.xfs 3.2.3 enabled by default the new V5 format (-m crc=1,finobt=1). Current Sysrcd's default kernel (3.14) can not even mount the volume. It experimentally supports -m crc=1 (stable upstream since 3.15), but not -m finobt=1 (supported since 3.16, mkfs.xfs 3.2.1). To complicate things more, mkfs.xfs 4.2.0 also enabled by default -n ftype=1 (supported since mkfs.xfs 3.2.0) for V4 volumes (ftype is madatory in V5).

-m crc=0 (V4) with -n ftype=1 is supported since kernel 3.13. And currently it breaks GRUB: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768659 (but GRUB supports V5 just fine)

So FSArchiver needs at minimum always create XFSv4 file systems without ftype (-n ftype=0 in case mkfs.xfs 4.2.0+ is used) until proper V5 support gets added.

See:
http://oss.sgi.com/pipermail/xfs/2015-November/045153.html
http://oss.sgi.com/pipermail/xfs/2015-December/045195.html
http://oss.sgi.com/pipermail/xfs/2015-December/045462.html

@fdupoux
On Ubuntu 18.10 with fsarchiver 0.8.5-2:

Making the archive with:

fsarchiver -j 3 -v -o -A -Z 21 savefs file.fsa /dev/sda2

Restoring it with:

fsarchiver -j 4 -v restfs file.fsa id=0,dest=/dev/sda2

leads to:

archreader.c#329,archreader_read_header(): archive-id in header does not match: archid=[5bc60eba], expected=[5bc60f17]
archreader.c#329,archreader_read_header(): archive-id in header does not match: archid=[5bc60eba], expected=[5bc60f17]
archreader.c#329,archreader_read_header(): archive-id in header does not match: archid=[5bc60eba], expected=[5bc60f17]
archreader.c#329,archreader_read_header(): archive-id in header does not match: archid=[5bc60eba], expected=[5bc60f17]
archreader.c#329,archreader_read_header(): archive-id in header does not match: archid=[5bc60eba], expected=[5bc60f17]
archreader.c#329,archreader_read_header(): archive-id in header does not match: archid=[5bc60eba], expected=[5bc60f17]
queue.c#600,queue_dequeue_header_internal(): dequeue - wrong type of data in the queue: expected a dico and found a block
oper_restore.c#1483,oper_restore(): queue_dequeue_header() failed: cannot read filesystem-info dico

What could be done to workaround that issue?

My error. Problem resolved. Thank you!

Would it be possible to add support for the f2fs format?

I appreciate the addition of support (shown in the change log) for FAT (I assume FAT32) to support archives of disks that have an EFS (EFI file system).

There are places on your site which don't list support for FAT, and in your FAQ, you expressly deny support for FAT. This should be updated.

BTW, FSArchiver's previous lack of support for the EFS caused me to look elsewhere for a solution last year.

I've used FSArchiver over many years, though not very often. Usually when doing a backup and restore for a new installation.

I just looked at the http://www.fsarchiver.org/partimage/ and ZFS is not mentioned. It's not mentioned elsewhere on the FSArchiver site either. I'm thinking of switching to ZFS at some point, and so I was wondering if ZFS is not supported, or the documentation just forgot to mention it.

If it is not supported, what is the problem, and is it possible support might arrive at some point?

How can get backup with keep all flag files; for example Immutable, Append_Only,...

I tested, but fsarchiver doesn't backup from flags files.

See my testing:

I create an immutable file: (chattr +ia /a/immutable_file) and can see ia flag.

root@sysresccd /root % 
root@sysresccd /root % ls -lah /a
total 32K
drwxr-xr-x  4 root root 4.0K May  7 03:08 .
drwxrwxrwt 32 root root  280 May  7 02:44 ..
drwxr-xr-x  2 root root 4.0K May  6 03:48 aaa
-rw-r--r--  1 root root    6 May  7 03:02 immutable_file
drwx------  2 root root  16K May  6 03:45 lost+found
-r-----r--  1  999 root   15 May  7 02:29 ubuntu
root@sysresccd /root % chattr +ia /a/immutable_file 
root@sysresccd /root % lsattr /a
--------------e---- /a/lost+found
----ia--------e---- /a/immutable_file
--------------e---- /a/ubuntu
--------------e---- /a/aaa
root@sysresccd /root % 

Now I backup partition:

root@sysresccd /root % umount /a
root@sysresccd /root % 
root@sysresccd /root % fsarchiver savefs -v -j8 -z0 -o backup.fsa /dev/sdb1
Legacy compression methods (-z) are deprecated.
It is recommended to switch to zstd using the -Z option.
Please read "http://www.fsarchiver.org/Compression" for more details.
Analysing filesystem on /dev/sdb1...
============= archiving filesystem /dev/sdb1 =============
-[00][ 19%][DIR     ] /
-[00][ 39%][DIR     ] /lost+found
-[00][ 59%][REGFILEM] /immutable_file
-[00][ 80%][REGFILEM] /ubuntu
-[00][100%][DIR     ] /aaa
Statistics for filesystem 0
* files successfully processed:....regfiles=2, directories=3, symlinks=0, hardlinks=0, specials=0
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0
root@sysresccd /root % 
root@sysresccd /root % 

Now restore it:

root@sysresccd /root % fsarchiver restfs -v -j8 backup.fsa id=0,dest=/dev/sdb1,mkfsopt="-i 1024"
============= extracting filesystem 0 =============
executing [mke2fs -V]...
command [mke2fs -V] returned 0
executing [mke2fs -V]...
command [mke2fs -V] returned 0
executing [mke2fs /dev/sdb1  -q  -F  -r 1  -i 1024  -b 4096  -L 'aaaaa'  -I 256  -O has_journal,ext_attr,resize_inode,dir_index,^sparse_super2,filetype,extent,^journal_dev,flex_bg,^meta_bg,^mmp,64bit,^inline_data,large_file,huge_file,sparse_super,^uninit_bg,dir_nlink,extra_isize,^bigalloc,metadata_csum,^project ]...
command [mke2fs /dev/sdb1  -q  -F  -r 1  -i 1024  -b 4096  -L 'aaaaa'  -I 256  -O has_journal,ext_attr,resize_inode,dir_index,^sparse_super2,filetype,extent,^journal_dev,flex_bg,^meta_bg,^mmp,64bit,^inline_data,large_file,huge_file,sparse_super,^uninit_bg,dir_nlink,extra_isize,^bigalloc,metadata_csum,^project ] returned 0
executing [tune2fs /dev/sdb1  -U 47849ac4-0cba-4fde-b7f0-0c22b159ad13  -o user_xattr,acl  -c 0  -i 0d ]...
command [tune2fs /dev/sdb1  -U 47849ac4-0cba-4fde-b7f0-0c22b159ad13  -o user_xattr,acl  -c 0  -i 0d ] returned 0
Mount information: []
-[00][ 19%][DIR     ] /
-[00][ 39%][DIR     ] /lost+found
-[00][ 59%][DIR     ] /aaa
-[00][ 79%][REGFILEM] /immutable_file
-[00][100%][REGFILEM] /ubuntu
Statistics for filesystem 0
* files successfully processed:....regfiles=2, directories=3, symlinks=0, hardlinks=0, specials=0
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0
root@sysresccd /root % 
root@sysresccd /root % 

Now you can see remove flags(-ia-) file after lsattr command:

root@sysresccd /root % mount /dev/sdb1 /a                                                       
root@sysresccd /root % 
root@sysresccd /root % ls -lah /a
total 32K
drwxr-xr-x  4 root root 4.0K May  7 03:11 .
drwxrwxrwt 32 root root  280 May  7 02:44 ..
drwxr-xr-x  2 root root 4.0K May  6 03:48 aaa
-rw-r--r--  1 root root    6 May  7 03:02 immutable_file
drwx------  2 root root  16K May  6 03:45 lost+found
-r-----r--  1  999 root   15 May  7 02:29 ubuntu
root@sysresccd /root % lsattr /a
--------------e---- /a/aaa
--------------e---- /a/immutable_file
--------------e---- /a/lost+found
--------------e---- /a/ubuntu
root@sysresccd /root % 

I attempted to register with the fsarchiver board but never got the confirmation e-mail, so was unable to post this question there.

I would like to utilize this program, given it's wide range of stated capabilities. I have used it and tested it for some basic save/restore operations, but concerned about the lack of activity on the community forum. Is the author actively supporting it?

Thanks in advance.

Hello. I want to say a big thank you right away for your fsarchiver product.
I am implementing an idea of ​​the following nature: the files themselves are not stored in the archive, but on the ipfs host.
I think this can improve your product and expand its functionality.
This is done using REGFILE_NODATA, which is activated with the --no-data option. It is similar in structure to the REGFILE_UNIQUE of an empty file.
The files themselves are uploaded to the ipfs server using curl.
If I offer you a merge, can I expect to merge my code into the main branch, or are you not interested?
The code is still in a bad state, I implemented it only to test the idea itself.
I look forward to hearing, thank you very much.

Links:
https://gitlab.com/mistikanil/fsarchiver-ipfs/-/tree/ipfs
https://docs.ipfs.io/reference/http/api/#getting-started

Downstream issue.

In order to obtain files from the .fsa archive I use this simple trick:

1. Creating a dummy block:

$ dd if=/dev/zero of=test.img count=1024 bs=1M
1024+0 records in
1024+0 records out

2. Creating a loop device:

$ losetup /dev/loop0 test.img
$ losetup -a
/dev/loop/0: []: (/home/my_user/test.img)

3. Restoring .fsa:

$ fsarchiver restfs backup_test.fsa id=0,dest=/dev/loop0

In the third step, fsarchiver throws this error:

fs_ext2.c#373,extfs_mkfs(): command [mke2fs /dev/loop0  -q  -F    -b 4096  -U 3671e993-ecaa-44a9-baca-89935e15ffa9  -I 256  -r 1  -O has_journal,ext_attr,resize_inode,dir_index,^sparse_super2,filetype,extent,^journal_dev,flex_bg,^meta_bg,^mmp,64bit,^inline_data,^ea_inode,^large_dir,large_file,huge_file,sparse_super,^uninit_bg,dir_nlink,extra_isize,^bigalloc,metadata_csum,^project ] failed with return status=1
oper_restore.c#1296,extractar_filesystem_extract(): cannot make filesystem ext4 on partition /dev/loop0

I am using Alpine Linux distribution, which in turn uses musl libc and busybox as user space toolset.

Hi,

I tried to compile fsarchiver with latest attr package version 2.4.48, but now it fails to build due to a missing include:

configure: error: attr/xattr.h not found. you may have to install a package called attr, libattr, libattr-devel
fsarchiver_build_log.txt

Bonjour,
J'ai sauvé un répertoire (savedir) sur système de fichier ext4 qui contenait un lien symbolique relatif à une autre partition ext4.
A la restauration (restdir) j'obtiens le message:
[errno=17, File exists]: oper_restore.c#401, extractar_restore_obj_symlink(): symlink(/usr/lib/pgaccess/lib, /mnt/myself/mnt/myself/Bin/lib) failed
lien symbolique original dans le répertoire myself/Bin : lib -> /usr/lib/pgaccess/lib
Je précise que le répertoire Bin est supprimé totalement avant restauration.

Aucun problème rencontré sur le même lien symbolique en utilisant les option savefs/restfs.

Merci d'avance pour toute réponse, cordialement,
Rémi.

====
English version :
Hello !
When I save and restore a directory (ext4 filesystem) with this symbolic link in myself/Bin directory: lib -> /usr/lib/pgaccess/lib
(link is pointing to antoher partition)
I get this message:
[errno=17, File exists]: oper_restore.c#401, extractar_restore_obj_symlink(): symlink(/usr/lib/pgaccess/lib, /mnt/myself/mnt/myself/Bin/lib) failed
Note : Bin directory is fully deleted before starting fasrchiver restdir command
No errors with same directory using savefs/restfs fsarchiver options.

Thanks for any answer, regards,
Rémi.

Most distributions target the latest stable release and latest fsarchiver has been issued ~2 years ago, maybe we can prepare a new one?

In particular, an important fix was merged for musl-based distributions, which should fix my issue.

Details in #1.

Now that FSArchiver 0.6.20+ stores XFS filesystem version, it must choose depending on mkfs.xfs version correct command line options for XFSv5.

       |     3.2.0     |    3.2.1    |    3.2.2    |  3.2.3+
-------|---------------|-------------|-------------|-----------
crc    | supported,    | supported,  | supported,  | supported,
       | not default   | not default | not default | default
-------|---------------|-------------|-------------|-----------
finobt | not supported | supported,  | supported,  | supported,
       |               | not default | not default | default

Versions older than 3.2.0 do not support V5 format.

-m crc=1,finobt=0 is supported since kernel 3.15. -m crc=1,finobt=1 since 3.16.

We can start with this:

if (xfsprogs < 3.2.0)
    error out
else
    /* 3.2.0-3.2.2 will set -m crc=1,finobt=0
       3.2.3+ will set -m crc=1,finobt=1 */
    mkfs.xfs -m crc=1

See also #4 about UUID change issue.

In my use case I often need to duplicate an image to different machines. After restore, I regenerate filesystem UUID, among other changes (machine-id, fstab, grub config). Now with XFSv5 this workflow does not work anymore, because xfs_admin will bump minimum kernel to 4.3 (see #4) and my target systems will choke (and SystemRescueCd's 3.18 and 4.1 kernels BTW). FSArchiver behaviour today is fine, as it by default correctly keeps original UUID, which is sane IMO.

Having the ability to specify via command line a predefined UUID (overriding the one present in the image) would help. It would also be helpful for other filesystems, as running specific fs tool (tune2fs, xfs_admin, reiserfstune, etc.) after restfs would not be necessary for folks that need a new UUID.

I could use a shell script like this (assuming new option is named uuid=):

newuuid=$(uuidgen)
fsarchiver restfs foo.fsa id=0,dest=/dev/bar,uuid=${newuuid}

Then use ${newuuid} to configure target system.

What do you think?

Thank you for your great work on fsarchiver!
0.6.22 seems to be the latest version that has a static i386 download on github, would it be possible that you re-start to include i386 binaries in future releases?

I reckon that there aren't many 32bit systems left, but there are still some :-)

Suppose we created fs backup with 10GB database or multimedia and few kilobytes got corrupted.
Removing the whole file during restore in case of such corruption is very undesirable.
Simply because there are no other backups.
So fsarchiver should have an option to preserve corrupted files.

Does iocharset=foo/utf8 mess [1] affect FSArchiver 0.8.0+?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833238

IOW, does it need to pass any safe mount options to generic_mount() in vfat_mount()?

[1] Debian's default is iocharset=utf8. In Ubuntu is iocharset=iso8859-1. Fedora OTH uses iocharset=ascii...