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

How to integrate with HyperBackup or backup installed apps like Transmission #4174

Closed
vjayer opened this issue Sep 11, 2020 · 5 comments
Closed

Comments

@vjayer
Copy link

vjayer commented Sep 11, 2020

#2294 # Setup
Package Name: Transmission
Package Version: v3.00-18

NAS Model: ds415+
NAS Architecture: x86
DSM version: DSM 6.2.3-25426 Update 2

Expected behavior

HyperBackup shows SynoCommunity pkgs

Actual behavior

HyperBackup ignores SynoCommunity pkgs

Steps to reproduce

Install Transmission and setup HyperBackup task

Is there a way to make HyperBackup recognize synocommunity programs?
If not, how do we backup its configuration and current state?
For example, how would we do this for Transmission?

@BenjV
Copy link

BenjV commented Sep 11, 2020

HyperBackup does not have any knowledge of third party packages so that is not possible.

Configuration backup is the responsibility of the application.
All well designed applications should have the ability to make a backup of its configuration.

@vjayer
Copy link
Author

vjayer commented Sep 13, 2020

thanks for the reply. It's too bad we can't have automated third party app backup.
As for Transmission, without saving the entire package installation and only focusing on configuration/settings, these dirs and files are what I figured to backup in case I have to reinstall:

cat transmission_conf_files.txt
/var/packages/transmission/etc/installer-variables
/var/packages/transmission/target/var/blocklists
/var/packages/transmission/target/var/resume
/var/packages/transmission/target/var/torrents
/var/packages/transmission/target/var/settings.json
/var/packages/transmission/target/var/stats.json

zip -@ -9 -r transmission_conf.zip < transmission_conf_files.txt

There's also the workaround mentioned in #4101 but I left that file out in case it's fixed in a future version and I do not want to overwrite files that are normally not preferences/settings

@BenjV
Copy link

BenjV commented Sep 13, 2020

It is not difficult to backup/restore the config of applications, but for a package as HyperBackup it must know what to backup and where to find it.
And Synology does not specify such a thing for third party packages so you end up with a point solution for every application.

@hgy59 hgy59 closed this as completed Feb 25, 2021
@ymartin59
Copy link
Contributor

@hgy59 @BenjV I agree there is no documentation about how to backup/restore in DSM developer guide but I quote <<Hyper Backup allows you to back up various kinds of data (system configurations, shared folders, and applications/packages) on your Synology>> from https://www.synology.com/en-global/knowledgebase/DSM/help/HyperBackup/data_backup
So I wonder if Hyper Backup simply does a list of installed packages and (hopefully) create an archive of package "target" folder...

@BenjV
Copy link

BenjV commented Mar 16, 2021

No Hyper Backup does that only for native Synology application/packages.
And backing up the "target" folder of a package is not enough.
All the administration that the package center does when installing has te be included in the backup, also user/groups who are created should be in the backup/restore.

And Hyper Backup will only backup data from a shared folder, so a package "target" folder cannot be chosen as a backup source.

A solution would be to create somewhere in a shared folder simlinks to every 'target' package folder on the system which could be use by Hyper Back
A complete restore of a package would then be to install the package fresh so all the DSM administration is correct, then stop the package and restore the appropriate 'target' folder.

This would only work for SynoCommunity packages (providing they are created correctly), because during "uninstall" of a package the internal package user is removed in the script.
If it is not in the script that user stays on the system and installing the same package fresh will result in new internal user which could create permissions issues, because the restored 'target' folder would be owned by the old user.

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

4 participants