thenickdude / snap-to-s3

Upload EBS volume snapshots to Amazon S3/Glacier
Other
114 stars 24 forks source link

copying procees failing when there are two disks/mount points are there in a snapshot. #10

Closed santoshkatageri closed 4 years ago

santoshkatageri commented 4 years ago

`Uploading partition 2 of 2... [snap-xxx] Mounting /dev/xvdy128 at /mnt/snap-xxxx-128... [snap-xxxxx] An error occurred, tagging snapshot with "migrate" so it can be retried later [snap-xxxx] { Error: snap-xxxx: mount --source /dev/xvdy128 --target /mnt/snap-xxx-128 --read-only failed: mount: /mnt/snap-xxxx-128: wrong fs type, bad option, bad superblock on /dev/xvdy128, missing codepage or helper program, or other error.

at SnapshotMigrationError (/usr/lib/node_modules/snap-to-s3/lib/snap-to-s3.js:1957:3)
at _raceToMarkSnapshot.then.then (/usr/lib/node_modules/snap-to-s3/lib/snap-to-s3.js:1691:12)
at process._tickDomainCallback (internal/process/next_tick.js:135:7)

error: 'mount --source /dev/xvdy128 --target /mnt/snap-xxxxx-128 --read-only failed: mount: /mnt/snap-xxxxx-128: wrong fs type, bad option, bad superblock on /dev/xvdy128, missing codepage or helper program, or other error.\n', snapshotID: 'snap-xxxxxx' }`

thenickdude commented 4 years ago

Can you double check what that partition is and if you can mount it manually? Your OS may be missing support for that filesystem.

You may find extra detail on the error in dmesg and syslog

thenickdude commented 4 years ago

It looks like that partition on Amazon Linux 2 is identified as "BIOS boot" by fdisk, which is a partition to hold the bootloader for BIOS booting on GPT format disks. This causes snap-to-s3 to fail because the partition doesn't contain a mountable filesystem.

At the moment you could only back up such disks by adding the "--dd" option to snap-to-s3, which will cause it to make an image of the entire disk instead of mounting the filesystems and using tar.

Unfortunately I didn't design snap-to-s3 to allow it to create a tar of filesystems it can mount and use DD for the rest. Perhaps it could be made to ignore BIOS boot partitions specifically, but it seems poor practice for a backup tool to intentionally not back up some portions of the disk.

santoshkatageri commented 4 years ago

I can see that the second partition was for BIOS boot which was not recognized. I don't think we need to copy this along with the snapshot. I tried Fdisk on the ec2 machine I got output like below.

`Disk /dev/xvdp: 50 GiB, 53687091200 bytes, 104857600 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: ACxxxxxxx9-6x3x-44xx-8C9F-6xxxxxxxx3

Device Start End Sectors Size Type /dev/xvdp1 4096 104857566 104853471 50G Linux filesystem /dev/xvdp128 2048 4095 2048 1M BIOS boot`

Hope this is not an issue with the tool.