Restoring a Linux backup on Windows fails - "Invalid child node name"

Getting Help
1

I am trying to back up my NAS (omv6) on a Windows 10 machine. I got my restic (for Windows) set up and backed up a few files from a shared folder - so far so good.

But when I try to restore them - either in Windows or back onto the NAS, I am getting “Invalid child node name” errors and nothing get’s restored.

Am I doing something wrong? Is there a problem crossing from linux to windows during the backup? (the files show up in the snapshot just fine) Why can’t I restore them back to the linux environment (my NAS) either?

2

Please be more specific :slight_smile: Make sure you run the latest restic version (0.16.0 as of writing this), show us the complete command you run and all of its output when you try to restore, and please also the same for the command that you use to back up the data you try to restore.

If it helps you can try to use the :subfolder syntax of the restore command to cut off the first parts of the path to restore, see this discussion for some examples and references. It all depends on what the error message is about.

3

can do @rawtaz …

the setup:

  • NAS:
    – hardware: old HP mircoserver N40l with several drives on the network (named “Microserver”)
    – software: openmediavault6 (debian linux based, up to date)
    – configuration: two HDDs in mergerFS pool w several shared folders in it
  • client:
    – hardware: Windows 10 desktop (named “Stewie”)
    – software: retic-0.16.0_windows_amd64 from GitHub downloaded & working

the process:

  • (all commands given via client side PowerShell)
  • local repository created on D: …

restic init -r d:/restic_BU

  • (folder & structure created successfully)
> ID        Time                 Host        Tags        Paths
> ----------------------------------------------------------------------------------
> 19f86de1  2023-09-01 00:03:01  Stewie                  \\MICROSERVER\pictures\test
> ----------------------------------------------------------------------------------
  • test backup:

restic -r d:/restic_BU backup \MICROSERVER\pictures\test

→ (backup was successful - snaphot created … and the “restic_BU” folder is now roughly the size of the “test” folder) … (fyi, “pictures” a shared folder on the NAS, “test” a folder with 5 pictures in it)

  • looking at the snaphot … shows the files

restic -r d:/restic_BU ls 19f86de1

repository fc10dcae opened (version 2, compression level auto)
snapshot 19f86de1 of [\\MICROSERVER\pictures\test] filtered by [] at 2023-09-01 00:03:01.0041974 -0500 CDT):
/\\MICROSERVER\pictures
/\\MICROSERVER\pictures/test
/\\MICROSERVER\pictures/test/IMG_3660.JPG
/\\MICROSERVER\pictures/test/IMG_3663.JPG
/\\MICROSERVER\pictures/test/IMG_3713.JPG
/\\MICROSERVER\pictures/test/IMG_4011.JPG
/\\MICROSERVER\pictures/test/toddler.jpg

so far so good … now comes the tricky part:

  • created folder “restored” on C:
  • test restore:

restic -r d:/restic_BU restore latest –target c:/restored

  • result:
repository fc10dcae opened (version 2, compression level auto)
restoring <Snapshot 19f86de1 of [\\MICROSERVER\pictures\test] at 2023-09-01 00:03:01.0041974 -0500 CDT by Stewie\Hauke@Stewie> to c:/restored
ignoring error for \: invalid child node name \\MICROSERVER\pictures
ignoring error for \: invalid child node name \\MICROSERVER\pictures
Summary: Restored 0 Files (0 B) in 0:00
Fatal: There were 2 errors
  • things I also tried … (with the exact same result):
    – snaphot ID instead of “latest”
    – target: \mircoserver\suscha (another shared folder on the NAS)
    – target: \mircoserver\pictures (original shared folder data came from)
1 Like
4

Thanks for splendid elaboration!

It seems to me that Windows doesn’t like it when restic tries to create the path components \\MICROSERVER\pictures, it’s probably the first part of those two that’s the problem.

One thing you can try just to see if it works is to mount \\MICROSERVER\pictures to a drive letter and then back up that drive letter instead. I’m guessing this works better to restore.

Another thing to try just out of curiosity is to use the following restore command: restic -r d:/restic_BU restore latest:\\MICROSERVER --target c:/restored. You might have to quote or otherwise escape the backslashes to make them survive the command interpreter/your shell, I can’t really say what the proper way to do that in the context you are running it in is, you can experiment. I’m hoping this would make restic not try to create the \\MICROSERVER part when restoring the folder structure.

1 Like
5

well @rawtaz … looks like you’re on to something

I mounted \\MICROSERVER\pictures as Z: … and ran the backup again: restic -r d:/restic_BU backup z:/test …:

repository fc10dcae opened (version 2, compression level auto)
no parent snapshot found, will read all files

Files:           5 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added to the repository: 293 B (253 B stored)

processed 5 files, 1.988 MiB in 0:00
snapshot a711f72d saved

here are the files in the snapshot restic -r d:/restic_BU ls a711f72d …:

repository fc10dcae opened (version 2, compression level auto)
snapshot a711f72d of [z:\test] filtered by [] at 2023-09-01 13:59:11.2227456 -0500 CDT):
/z
/z/test
/z/test/IMG_3660.JPG
/z/test/IMG_3663.JPG
/z/test/IMG_3713.JPG
/z/test/IMG_4011.JPG
/z/test/toddler.jpg

I then restored to C: via restic -r d:/restic_BU restore latest --target c:/restored …:

repository fc10dcae opened (version 2, compression level auto)
restoring <Snapshot a711f72d of [z:\test] at 2023-09-01 13:59:11.2227456 -0500 CDT by Stewie\Hauke@Stewie> to c:/restored
Summary: Restored 7 Files (1.988 MiB) in 0:00

and the same to the NAS using the drive letter (same share, but new folder) restic -r d:/restic_BU restore latest --target z:/test2 …:

repository fc10dcae opened (version 2, compression level auto)
restoring <Snapshot a711f72d of [z:\test] at 2023-09-01 13:59:11.2227456 -0500 CDT by Stewie\Hauke@Stewie> to z:/test2
Summary: Restored 7 Files (1.988 MiB) in 0:00

It restores the folder test (with its contents) inside a folder z inside the target folder in both cases.

I then wanted to see if the creation of the snapshot was the only culprit, so I tried to restore using the network path \\MICROSERVER\sucha again … and that failed again (now with “\z: node has invalid path”):

repository fc10dcae opened (version 2, compression level auto)
restoring <Snapshot a711f72d of [z:\test] at 2023-09-01 13:59:11.2227456 -0500 CDT by Stewie\Hauke@Stewie> to \\microserver\suscha
ignoring error for \z: node has invalid path
ignoring error for \z: node has invalid path
Summary: Restored 0 Files (0 B) in 0:00
Fatal: There were 2 errors

So I guess this is a viable workaround for now … having less than a dozen shared folder, I guess I can muster letters O through Z for mounting purposes on that system. Do you think this a bug and is anyone working on a permanent fix?

I also tried the restore command you asked me to try: restic -r d:/restic_BU restore latest:\\MICROSERVER --target c:/restored … first on the snapshot I had just created Z:, and then on one I created with the network path \\MICROSERVER\pictures again. Both times it “failed” the same way:

repository fc10dcae opened (version 2, compression level auto)
path \\MICROSERVER: not found
6

This is actually a know bug: Restore of UNC Paths within windows failing (reproducible) · Issue #2807 · restic/restic · GitHub

AFAIR \\MICROSERVER\pictures is a single folder name in the snapshot. Thus, restic -r d:/restic_BU restore latest:\\MICROSERVER\pictures --target c:/restored might work.

What are the first paths printed by restic ls latest?