Force a full image volume backup with ZFS backend

How can we force a full image volume backup when using ZFS backend storage (ie without starting from last backup) ?
When using ZFS, it uses “forever incremental” image backup style.
The problem is that since few weeks, image backups of one of the 3 volumes we are backing up are unmountable, i.e the raw file cannot be mounted and browsed through GUI nor with a tool like OSF Mount …

Regards,

When i try to mount the RAW image file, i’ve got :

Under Windows woth OSFMount tool :

Then

Under Linux on the UrBackup server :

root@backup-1:/media/backups/SV403/171104-2238_Image_T# fdisk -l Image_T_171104-2238.raw

Disque Image_T_171104-2238.raw : 120 GiB, 128846396928 octets, 251653119 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Type d’étiquette de disque : dos
Identifiant de disque : 0x6aae07f0

Device Boot Start End Sectors Size Id Type
Image_T_171104-2238.raw1 * 1024 251653118 251652095 120G 7 HPFS/NTFS/exFAT

root@backup-1:/media/backups/SV403/171104-2238_Image_T# mount -o loop,ro,offset=524288 Image_T_171104-2238.raw /mnt/loop
$MFTMirr does not match $MFT (record 0).
Failed to mount ‘/dev/loop0’: Erreur d’entrée/sortie
NTFS is either inconsistent, or there is a hardware fault, or it’s a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the ‘dmraid’ documentation
for more details.
root@backup-1:/media/backups/SV403/171104-2238_Image_T# mount -o loop,offset=524288 Image_T_171104-2238.raw /mnt/loop
$MFTMirr does not match $MFT (record 0).
Failed to mount ‘/dev/loop0’: Erreur d’entrée/sortie
NTFS is either inconsistent, or there is a hardware fault, or it’s a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the ‘dmraid’ documentation
for more details.
root@backup-1:/media/backups/SV403/171104-2238_Image_T#

It looks like the MFT is corrupted in the image, but doesn’t find a way to fix it …

I try to start from the last valid backup of the volume (23/09/2017) :

cd /media/backups/SV403/171106-2239_Image_T/
cp /media/backups/SV403/170923-2240_Image_T/Image_T_170923-2240.raw Image_T_171106-2239.raw
cp /media/backups/SV403/170923-2240_Image_T/Image_T_170923-2240.raw.bitmap Image_T_171106-2239.raw.bitmap
cp /media/backups/SV403/170923-2240_Image_T/Image_T_170923-2240.raw.cbitmap Image_T_171106-2239.raw.cbitmap
cp /media/backups/SV403/170923-2240_Image_T/Image_T_170923-2240.raw.hash Image_T_171106-2239.raw.hash
cp /media/backups/SV403/170923-2240_Image_T/Image_T_170923-2240.raw.mbr Image_T_171106-2239.raw.mbr
cp /media/backups/SV403/170923-2240_Image_T/Image_T_170923-2240.raw.sync Image_T_171106-2239.raw.sync
zfs destroy backups/images/SV403/171106-2239_Image_T@ro
zfs snapshot backups/images/SV403/171106-2239_Image_T@ro

Next backup was successful tonight but RAW file produced is still unmountable …
Maybe a reset of the CBT layer on the client or uninstall / reinstall the client should fix the pb ?

Regards,

Yeah, cbt reset with
cd C:\Program files\UrBackup
urbctclt reset x:

may help. Can you also investigate if only MFT!=MFTMirr is the problem? Use losetup --offset=$((512*1024)) to setup the volume. Then use ntfsfix to fix the NTFS error.
If this is something the naturally occurs, there is already code in UrBackup to fix it…

Thanks
I’ve uninstall the client, force run a chkdsk on the volume, rebooting the client, reinstall the client and rebooting twice to activate CBT on the volumes.
We’ll see tomorrow for the result …

root@backup-1:/media/backups/SV403/171107-2240_Image_T# losetup --offset=$((512*1024)) /dev/loop4 Image_T_171107-2240.raw root@backup-1:/media/backups/SV403/171107-2240_Image_T# ntfsfix /dev/loop4 Mounting volume... $MFTMirr does not match $MFT (record 0). FAILED Attempting to correct errors... Processing $MFT and $MFTMirr... Reading $MFT... OK Reading $MFTMirr... OK Comparing $MFTMirr to $MFT... FAILED Correcting differences in $MFTMirr record 0...ntfs_attr_mst_pwrite: written=-1: Operation not permitted Error writing $Mft record(s): Operation not permitted FAILED Error correcting $MFTMirr: Operation not permitted root@backup-1:/media/backups/SV403/171107-2240_Image_T# losetup -l NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE /dev/loop4 0 524288 0 1 /media/backups/images/SV403/171107-2240_Image_T/Image_T_171107-2240.raw root@backup-1:/media/backups/SV403/171107-2240_Image_T#

I don’t know why, losetup set my loop device as read-only …

I thought the ZFS datasets would be read-write, but maybe they are not?

Yes they are …

root@backup-1:/media/backups/SV403# zfs get all /media/backups/SV403/171107-2240_Image_T NAME PROPERTY VALUE SOURCE backups/images/SV403/171107-2240_Image_T type filesystem - backups/images/SV403/171107-2240_Image_T creation mar. nov. 7 22:40 2017 - backups/images/SV403/171107-2240_Image_T used 10,6G - backups/images/SV403/171107-2240_Image_T available 2,29T - backups/images/SV403/171107-2240_Image_T referenced 23,7G - backups/images/SV403/171107-2240_Image_T compressratio 3.57x - backups/images/SV403/171107-2240_Image_T mounted yes - backups/images/SV403/171107-2240_Image_T origin backups/images/SV403/171106-2239_Image_T@ro - backups/images/SV403/171107-2240_Image_T quota none default backups/images/SV403/171107-2240_Image_T reservation none default backups/images/SV403/171107-2240_Image_T recordsize 128K default backups/images/SV403/171107-2240_Image_T mountpoint /media/backups/images/SV403/171107-2240_Image_T inherited from backups backups/images/SV403/171107-2240_Image_T sharenfs off default backups/images/SV403/171107-2240_Image_T checksum on default backups/images/SV403/171107-2240_Image_T compression lz4 inherited from backups/images backups/images/SV403/171107-2240_Image_T atime on default backups/images/SV403/171107-2240_Image_T devices on default backups/images/SV403/171107-2240_Image_T exec on default backups/images/SV403/171107-2240_Image_T setuid on default backups/images/SV403/171107-2240_Image_T readonly off default backups/images/SV403/171107-2240_Image_T zoned off default backups/images/SV403/171107-2240_Image_T snapdir hidden default [...]

Backup is okay today after uninstall / reinstall the client side.
I would be interested with ntfsfixing previous unmountable RAW images but still doesn’t understand why losetup set the loop device read-only …

Regards,