Other rsync (Invalid argument) and space

F

freejlr

I have been considering the procedures and applications that would have to be better for me to secure my data.

there are many possibilities to do it, cpio, tar, pax... They are some of the ones I have seen in chapter 18.10 of the handbook.

I thought that I thought that my best solution since my FreeBSD has the ZFS system is to use the snapshot function and the others that it has to facilitate this function.

But for non-ZFS filesystems like Fat32, NTFS would use rsync.

The first problem that I have with rsync is that being a fat32 system and the path seems to be that some of them have characters reserved:

Code: 
rsync: [sender] readlink_stat("/dir/???.mp3") failed: Invalid argument (22)

Apparently it's a character problem since du also has problems.

Code: 
du: /dir/???.mp3: Invalid argument

What would be the best way to deal with this kind of problem?

Surely, it will not be the first problem that I will see when trying to copy the hierarchy of a Windows system with NTFS etc...

Another thing that I did not understand is the following my zpool is the following:

Code: 
xus@m0:~ $ zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP       DEDUP    HEALTH  ALTROOT
zroot     117G  20.8G  96.2G        -              -               1%      17%      1.00x       ONLINE        -

##du

xus@m0:~ $ du -hs /


 21G

###df 

xus@m0:~ $ df -h
Filesystem                  Size    Used   Avail Capacity  Mounted on
zroot/ROOT/default    110G     18G     93G    16%    /

But when doing o following with rsync:

Code: 
xus@m0:~ $ rsync -anhv /
sent 9.69M bytes  received 40.06M bytes  2.69M bytes/sec
total size is 30.38G  speedup is 610.66 (DRY RUN)

I'm sure I'll be doing something wrong, but what's with that extra 10gb weight?

It is a ZFS system, the most correct thing would be to use its tools.

Regards.
 
Last edited by a moderator:
I was doing:

mount -t msdos /dev/da0s1 /media
Click to expand...

And I was ignoring all those options, in the end I solved it with your solution in this way. Before I had to load the module msdosfs_iconv:

kldload msdosfs_iconv
mount_msdosfs -L es_ES.UTF-8 -D CP850 /dev/da0s1 /media
Click to expand...

And with that you can solve the first problem, I will have to look at why rsync behaves that way when I want to make a copy of the root directory.

Regards.
 
freejlr said:
But when doing o following with rsync:


I'm sure I'll be doing something wrong, but what's with that extra 10gb weight?
Click to expand...
May be you have some files with holes such filesystem image or a file created/extended with truncate. As an example
Code: 
$ truncate -s 10M xyz
$ ls -s xyz
1 xyz
$ rsync -av xyz laptop:
sending incremental file list
xyz

sent 10,488,416 bytes  received 35 bytes  20,976,902.00 bytes/sec
total size is 10,485,760  speedup is 1.00
 
Why you do not try zpaq or zpaqfranz (* the latter is my own fork)?
For backup purpose way better than rsync

Turning back to this one: it is hard, very hard, to make a "real" copy with utf filenames
Even from "similar" (ex. bsd to macos), or "dissimilar" (bsd to linux)

It really is a kind of Vietnam or Afghanistan for systems engineers

If you want to make a copy of a folder on a device, such as eg. a USB disk, a NAS etc, with a certain reliability on the length of the path and type of characters, and you have enough local space, I recommend
1) take a snapshot
2) do a zpaq / zpaqfranz update of a local copy
3) destroy the snapshot
4) send with rsync --append on the USB disk or whatever it is

Alternatively you can do (but I don't recommend it, you lose version management) a zpaqfranz with comand r (robocopy / rsync) which has good support for non-Latin alphabets
However it is neither fast nor efficient
 
Example
you have tank, with a dataset d
You have "something" mounted in /media (USB, whatever)
then this will be directly write (without intermediate+rsync) the "franco" snapshot

Code: 
zfs destroy  tank/d@franco
zfs snapshot tank/d@franco
/usr/local/bin/zpaqfranz a /media/thebackupfile.zpaq /tank/d/.zfs/snapshot/franco -to /tank/d
zfs destroy tank/d@franco

Every time you run the new snapshot will be added to the backupfile.zpaq
With -key pippo you can encrypt the backup

If the backup filesystem cannot handle big files (FAT32 max 4GB) you can try with a multipart archive: /media/thebackupfile_????.zpaq
However, this approach fails if the single file to be archived is larger than 4GB.

In fact, with USB media, I suggest NTFS
Not very fast, but works

If you do not have to deal with "live" filesystems (aka: no need to snapshot, because the data folder is "frozen" until you change something) then a straight (for the /dir, /pippo /pluto/test folders)

Code: 
/usr/local/bin/zpaqfranz a /media/thebackupfile.zpaq /dir /pippo /pluto/test
is enough
 
If you are curious to find "strange" files (to sanitize before using rsync) you can run something like
Code: 
zpaqfranz utf /tank/d
WIth a -kill you can fix (of course the filenames will be changer, BEWARE!)
 
You must log in or register to reply here.
Back
Top