11

is there a way to recover snapshots to a share that has been completely deleted?

I tried moving my docker install over to my new ssd volume and used scp to move the @docker folder to the new volume so I wouldn't lose all my containers. I started getting permissions errors, but it seemed I had fixed them by starting the containers with pgid/puid as root, then changing back to the dockerlimited user and starting the containers again. seemed to work fine but then watchtower updated an image and it totally fried that container, with some btrfs can't remove subvolume issue. i couldn't delete, reset or start the container so it was like frozen. i tried to create a brand new container of the same image using portainer and it failed with another ocr init not found error. so i tried a nuclear option of chmod 777 of the entire @docker folder and i still wasn't able to create a container with portainer. it was giving the same error. so I figured the permissions and everything were so screwed up, the only thing to do is start from fresh. I used a docker-autocompose script to make compose files of all my containers and saved them in my docker shared folder.

Then i uninstalled container manager and checked the box to delete images, containers and shares. this deleted my docker share and the docker share i created as a backup. I think everything must still be there because even there's no share folders attributed to that volume, storage manager says theres still data on the drive. when i view usage details I see that snapshot is taking what i would expect to the correct amount for a full backup of the share folder i'd had but i can't tell for sure. Still I'm fairly positive the snapshot is my of my docker share. snapshot logs have this line from 5am today: 'Took a shared folder snapshot [GMT-05-2023.07.24-05.00.01] from share [docker] by [scheduler].'

How can I recover the share from the snapshot when the share doesn't exist anymore? If I create a new shared folder with the same name, would I be able to use the snapshot then? I'm honestly afraid to touch anything now because it seems at every step I just keep shooting myself in the foot and making things worse. Idk what to do.

you are viewing a single comment's thread
view the rest of the comments
[-] Scholars_Mate@lemmy.world 1 points 1 year ago

I'll preface this by saying I am not familiar with Synology, but I am using Docker and BTRFS (which I am assuming is being used on your Synology NAS).

Do you have SSH access or the ability to get a shell on the NAS? If you do, you can try running btrfs subvolume list . to see what subvolumes/snapshots are on your system. That will hopefully let you figure out where your data is. Once you narrow down where it is, you can try downloading it using an sftp client.

As an aside, the reason Docker threw a fit whenever you tried to update an image is that Docker was probably automatically using the BTRFS driver, which creates a new subvolume/snapshot for every image/layer. When you remove images, it would just remove all the subvolumes/snapshots. When you copied your files over, you probably didn't remake the subvolumes. That would have caused issues when trying to remove images, or create new images/containers.

[-] MonkCanatella@sh.itjust.works 1 points 1 year ago

Yes I can SSH in. I think the snapshot exists but is not mounted as a btrfs subvolume. In storage manager, it gives an overview of what's taking up space on your volume, and snapshots shows it taking up space so I'm certain it's there. the subvolume list on my other volume is showing the other snapshots I've created for other shared folders though.

from the research I did, the @docker folder at the volume root holds all the volumes, images, subvolumes, etc. and I did copy that over.

Do you happen to know if I find the snapshot folder and download it, will there be anything recoverable? Or would it just be like, hashes and unintelligble stuff?

[-] Scholars_Mate@lemmy.world 1 points 1 year ago

I think the snapshot exists but is not mounted as a btrfs subvolume.

Is it not listed when you try running btrfs subvolume list .? You might need to change the . to a path that is on the array.

from the research I did, the @docker folder at the volume root holds all the volumes, images, subvolumes, etc. and I did copy that over.

Copying over the files wouldn't be enough. You would actually need to create the subvolumes, e.g. btrfs subvolume create subvolume_name.

Do you happen to know if I find the snapshot folder and download it, will there be anything recoverable? Or would it just be like, hashes and unintelligble stuff?

Unfortunately, I am not familiar enough with how Synology does things, but a btrfs snapshot will just appear as normal directory with the files/directories in it. If Synology isn't using btrfs for the snapshoting, I'm not sure what you'll find.

this post was submitted on 24 Jul 2023
11 points (92.3% liked)

Selfhosted

40347 readers
182 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS