Feedback

[NicoHood]

Hi, I've just found your backup script which is now a fance package. Well done so far!
I've got some feedback which you might also apply to your software. If it gets enough votes on AUR I can also move this one to community. I'd love to do so ;)

• No help message is available
• The snapper configs to packup could be selectable via parameters: -c root home
• or via a config setting in the snapper file itself. For example: snapper get-config SNAP-SYNC_EXCLUDE=yes
• Readme typo: "Additionally you are show the location of the backed up snapshot."
• "Enter name of directory to store backups:" should make more clear that this is a relative path and it does not need to exist: "Enter name of relative directory to store backups (created if not existing):"
• Continue needs no "enter" only a "y". I personally do not like this behaviour.
• A quiet -q option is missing.
• Systemd timer for weekly/daily etc backups would be great.
• An optional -d --description option could add additional description to the snapshot. For example snap-sync weekly with the timer above
• Also copying the index file would be highly important to get the date of the snapshot
• If you have multiple configurations and do the first time backup it prompts you for the path, backups the subvol and then asks for the path of the next config. All those setting should be askes first.

If you ask me in general I'd use the snapper config files itself for additional settings. I'd start with an initital config check, if new configuration (appart root etc) were found. Then snap-sync will configure those and start the backup afterwards. The quiet uption would skip the setting but possibly print a warning for a new (not backuped) config.

This tool is totally awesome and really essential for everyones snapper setup. Thanks a lot for sharing!

[NicoHood]

What I also noticed is that snap-sync does not work across network. I've mounted my backup share via sftp and obviously it does not show up. A remote connection would be highly appreciated.

[wesbarnett]

Wow! This is a lot of great feedback. It's going to take me a little bit to address the items, but I'll definitely go through your comments. Thanks!

[wesbarnett]

When you talk about the index file, do you mean "info.xml"? If so, that is being copied to the backup location.

[NicoHood]

@wesbarnett Yes i mean the info file. But the info file is not copied at the moment, as it is outside the btrfs subvolume. Please check that.

It would be nice if you can only check the boxes above which are implemented yet. That'd at least give you an better overview of the TODO and I can test that then. :)

[wesbarnett]

Considering the info file, snapper actually doesn't store the info file in the snapshot, but stores it at the same directory level as the snapshot.

I'm checking things off as I open up issues for them (or if its simple after I fix it), so it's easier to track, rather than tracking everything here in one thread. I'm going to close this thread and direct discussion on the other items to their issues (if not covered there, feel free to comment here or open another issue).

[NicoHood]

You could also consider to use the dbus interface of snapper which could provide a more relyable connection. However I personally have zero knowledge in that field.

If you also wish to have some help on some features or more opinions I can try to help. I've got tons of stuff to work on, but this one really interrests me.

[NicoHood]

Thank you for applying the changes so far. When do you plan the next release (cause I want to test the changes and do not want to create a -git package)?

[wesbarnett]

I plan on doing a release within the next day or so.

[NicoHood]

Thanks :)

Dont missunderstand my issue reports, I was just intensively searching for bugs. I love this script, that really solves tons of backup problems.

Edit: and it is extremely good that you sign your releases. That really improves the security of the package! Great step forward!

[NicoHood]

I just found this:
https://github.com/doudou/snapsync

I have not tried it at all, but maybe it could give you new ideas.

[NicoHood]

How do you sign the releases? Do you tag a release, download it and then sign it? Or do you rather use some internal git commands?

[wesbarnett]

Create the release on Github, download the tarball, and sign it. Then edit the release on Github and add an additional file, choosing the signature.

[NicoHood]

Alright. However you should still verify the content of the github download. But its extremely great that you do those steps, as it really helps to secure the archlinux system against software manipulations.