Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to maintain this project? #115

Open
tkna91 opened this issue Jul 8, 2022 · 11 comments
Open

Is it possible to maintain this project? #115

tkna91 opened this issue Jul 8, 2022 · 11 comments

Comments

@tkna91
Copy link

tkna91 commented Jul 8, 2022

@qubidt Sorry if I offended you.
I see that you took over this project at #114, is it still difficult for you to maintain it?
I am not sure if I am allowed to use this tool since you have not even started merging pull requests or organizing issues.
If the project is not maintained and I can't find anyone else to take over, I would probably be better off looking for an alternative backup system, but since the tool is so complete, will that be a problem?
I have not yet tested or operated the tool.

I would appreciate anyone's honest opinion.
I am sorry if I have offended you.

@baodrate
Copy link
Owner

baodrate commented Jul 8, 2022

No offense taken. Sorry I haven't updated. I actually did merge most of the PRs in my fork before this repo was transferred over. I even have a bunch of refactoring I haven't committed yet because I wanted to set up tests and automation first. Unfortunately things piled up and I never got around to it.

I'll try to get this all done by this weekend. If I let it slip please feel free to ping me again.

@tkna91
Copy link
Author

tkna91 commented Jul 18, 2022

As for me, it seems that for now I have found a simpler alternative (rsync to btrfs managed by snapper) and I don't have to use snap-sync.
However, I think closing it is also a problem, so if anyone is interested, please discuss.

@ohoes
Copy link

ohoes commented Aug 3, 2022

@qubidt

I think you've let it slip.

@tkna91

I'm still interested in the project.

@marccollin
Copy link

marccollin commented Sep 16, 2022

As for me, it seems that for now I have found a simpler alternative (rsync to btrfs managed by snapper) and I don't have to use snap-sync. However, I think closing it is also a problem, so if anyone is interested, please discuss.

you mean this project: https://github.com/thkukuk/rsync-backup ?

@tkna91
Copy link
Author

tkna91 commented Sep 16, 2022

@marccollin Sorry my English is not good enough to translate well.
I don't have the motivation to resolve this Issue because as a user I have found another alternative, but I think this Issue is necessary until releases and maintenance are resumed. If you need this project, you can discuss it in this Issue.

@tkna91
Copy link
Author

tkna91 commented Sep 18, 2022

@marccollin

you mean this project: https://github.com/thkukuk/rsync-backup ?

No. But the project sounds interesting as well.
My need is to store data from the main machine with snapshots on a separate backup server. Since it was not absolutely necessary to backup all snapshots on the main machine, I realized that it would be sufficient to transfer the current data via syncthing or rsync to the storage managed by the btrfs snapper on the backup server, which would be simpler and more flexible to changing circumstances. It was simpler and more flexible to adapt to changing circumstances.
And it has worked well in my case.

@evansan
Copy link

evansan commented Oct 4, 2022

@qubidt you let it slip

@real-user
Copy link

Is this project dead? I've been using ut for many years without issues, but it's worrying if no one maintain the project as it is relies so much on snapper that might change at any time.

@tkna91
Copy link
Author

tkna91 commented Dec 1, 2023

@real-user
If you are using btrfs only, I personally recommend btrbk.
You can also backup with btrfs send through ssh.
https://digint.ch/btrbk/

If you only want to do differential backups of local directories, you can set it up like this.

/etc/btrbk/btrbk.conf

snapshot_create         onchange
timestamp_format        long-iso
snapshot_preserve_min   3h
snapshot_preserve       24h 7d 4w 12m *y
target_preserve_min     3h
target_preserve         24h 7d 4w 12m *y
archive_preserve_min    3h
archive_preserve        24h 7d 4w 12m *y
archive_exclude         @swap

volume /mnt/.root_pool
    snapshot_dir @snapshots
    subvolume @
    subvolume @home
    subvolume @var_log

It is troublesome at first, but once set up, it is convenient.

@real-user
Copy link

Thanks for the suggestions @tkna91. I've been thinking to migrate to btrbk due to that snap-sync does seem to be abandonware at this point. But it is very sad as this software works perfectly and I like how it uses snapper.

Not that I am missing any feature in snap-sync and I like how it is integrated in snapper but it is in general never a good idea to rely on abandoned software in case any of the underlying libs/programs change in the future.

@tkna91
Copy link
Author

tkna91 commented Dec 3, 2023

@real-user I like btrbk because it works simpler than snapper.
There is no management by snapper-id or xml file. Just include the type stamp in the directory name and back it up using snapshot or btrfs-send|btrfs-receive.

There is an option to migrate to this, but I can't evaluate its merits or demerits.
https://github.com/rzerres/dsnap-sync

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants