#3026 Issue closed: Rsync backup method with backup url on a Windows server

Labels: support / question, no-issue-activity, old version

milleld1 opened issue at 2023-07-15 23:22:

  • ReaR version ("/usr/sbin/rear -V"): 2.4

  • If your ReaR version is not the current version, explain why you can't upgrade: The system has to use RHEL 7, and ReaR version 2.4 is the most recent version available for it.

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): RHEL 7.9

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"): see attached

  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR): Unknown

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): Unknown

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): Unknown

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): Unknown

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"): N/A

  • Description of the issue (ideally so that others can reproduce it):

Is there any known configuration to send backup files to a location on a Windows server?

I'm trying to send my backups via rsync to a location on another server running Windows. Cygwin has been set up for a long time and has worked normally. I have a nearly identical system using two linux servers instead of a linux server and windows server where the rsync method works perfectly. When I try to make a backup of the RHEL server onto Windows, it looks like most or all of the data I expected to be sent arrives safely, but I get a lot of errors in the rear log similar to these:

cp: cannot stat '/usr/share/microcode_ctl/ucode_with_caveats/intel/intel-ucode/06-86-04': No such file or directory

and

rsync: [generator] recv_generator: mkdir "/backup/thehostname/backup/etc/systemd/system/dev-virtio\x2dports-org.qemu.guest_agent.0.device.wants" failed: No such file or directory (2)
rsync: [generator] stat "/backup/thehostname/backup/usr/share/terminfo/A/Apple_Terminal" failed: No such file or directory (2)

I notice that these directories contain backslashes and underscores. Could there be some trouble with differences between Linux and Windows naming requirements? If Cygwin isn't handling these gracefully on its own, what can be done?

and

rsync: [receiver] mkstemp "/backup/thehostname/backup/opt/importantprogram/old/2017-01-12-235855/perl5.14.2/lib/5.14.2/Pod/Perldoc/.ModuleOne.pm" failed: No such file or directory (2)
rsync: [receiver] mkstemp "/backup/thehostname/backup/opt/importantprogram/old/2017-01-12-235855/perl5.14.2/lib/5.14.2/Pod/Perldoc/.ModuleTwo.pm" failed: No such file or directory (2)

My coworker notes that Cygwin doesn't have mkstemp, but uses a similar one called mktemp. Is there a known solution for backing up files to a Windows server?

  • Workaround, if any:

My coworker created a symbolic link to make calling mkstemp call mktemp instead. This worked in a manual test of rsync, but when rear runs, it isn't using that link. The error messages remain, showing that internally, rsync is calling mkstemp and this call is not changed to mktemp.

pcahyna commented at 2023-07-17 13:42:

I suggest that you test rsync alone (without ReaR) to back up your filesystem first and only when you have that working, integrate it with ReaR. Regarding Cygwin, I have no idea unfortunately.

pcahyna commented at 2023-07-17 13:46:

My coworker created a symbolic link to make calling mkstemp call mktemp instead.

What does this mean? How do you make calling mkstemp call mktemp? (They are C functions from libc.)

milleld1 commented at 2023-07-28 00:12:

Regarding mkstemp and mktemp,

we found manpages for these and saw they are very similar, and thought they might be interchangable, and made a symbolic link so that whenever mkstemp is called, mktemp is called instead. However, we were mistaken in thinking that this would accomplish anything. mkstemp is a system call, so setting this symlink did nothing of significance.

Regarding making rsync work alone,

It has been working until now, and it appears the reason it broke recently is solely due to differences in file naming rules between LInux and Windows. Until using ReAR we have never needed to use rsync with directories or files that have valid names in one system and invalid in the other.

We are exploring some different options. If I find something that works, I will update and close.

github-actions commented at 2023-09-26 02:03:

Stale issue message

[Export of Github issue for rear/rear.]