Hi,
Any of you who has any experience using CubeBackup, via Docker, on OpenMediaVault, to backup their Google Workspace or MS365?
Hi,
Any of you who has any experience using CubeBackup, via Docker, on OpenMediaVault, to backup their Google Workspace or MS365?
Were you able to find a solution?
Hi Snakyjake,
That was almost 2 years ago. I don't remember if I've found a solution or not. I think I simply recreated the VM from scratch... (It was a test VM so not much settings had been fiddled with).
Maybe someone could backup the settings somehow, create a new OMV VM from scratch and restore the settings? It looks like there isn't an easy way to do this.
Zitat
ZitatCan I backup or restore an existing openmediavault configuration?There is no regular backup/restore procedure, but yes, in some way: keep the file
/etc/openmediavault/config.xml
for references purposes if the option is to go for a clean re-install.
How to backup using openmediavault-backup plugin:
I have written quite a few posts about how to restore. This is probably the best one - How to restore from an omv-backup?
I hesitate on making anything much better because someone would try to cut & paste and make their system worse.
RE: How to backup and restore OMV configuration ? BMR Plan - howto?
Thanks for all your help KM0201.
I appreciate it!
I have this working fine with the following. The backup is operating normally, since yesterday.
version: "2"
services:
crashplan-pro:
hostname: docker-crashplan-OMV
container_name: crashplan-pro
image: jlesage/crashplan-pro
environment:
- "USER_ID=2028"
- "GROUP_ID=100"
ports:
- "5800:5800"
volumes:
- "/home/dockeruser/containerdata/CrashplanPro:/config"
- "/srv/dev-disk-by-label-NVMe500GB:/storage:ro"
Alles anzeigen
Your container goes to the webUi, but it doesn't show you the login screen. When it works normally, we see the login screen right away.
Maybe we shouldn't beat ourselves up with this one.
There might be a reason why some users put all their Docker config in Home/dockeruser/ folder?
Like this one:
RE: Docker: Where is the default location for config files / appdata?
I've tried the following and it's the same problem ([CrashPlanEngine] starting... over and over again)
version: "2"
services:
crashplan-pro:
hostname: docker-crashplan-OMV
container_name: crashplan-pro
image: jlesage/crashplan-pro
environment:
- "USER_ID=2028"
- "GROUP_ID=100"
ports:
- "5800:5800"
volumes:
- "/srv/dev-disk-by-label-NVMe500GB/Config__CrashplanPro:/config"
- "/srv/dev-disk-by-label-NVMe500GB/StorageTest:/storage:ro"
Alles anzeigen
StorageTest folder didn't exist before. It's Docker who created it. And weirdly if gives owner and group to root user.
But for the Config__CrashplanPro folder, which Docker also created (and which didn't previously exist either), it gives owner to dockeruser and group to users:
Isn't that odd?
Sure.
Thanks KM0201
I did create a new "config_crashplan" folder on the root of the data drive and did set: Owner:dockeruser rwx, Group:users rwx, Other rwx.
Then created a new docker like this:
version: "2"
services:
crashplan-pro:
hostname: docker-crashplan-OMV
container_name: crashplan-pro
image: jlesage/crashplan-pro
environment:
- "USER_ID=2028"
- "GROUP_ID=100"
ports:
- "5800:5800"
volumes:
- "/srv/dev-disk-by-label-NVMe500GB/config_crashplan:/config"
- "/srv/dev-disk-by-label-NVMe500GB:/storage:ro"
Alles anzeigen
Crashplan doesn't want to start with this.
Permissions of the config folder:
If I look at the permissions of one of the folders (bin) inside config_crashplan folder: (This was created by docker)
Everytime I create a new Shared Folder from OMV GUI, the owner is always set to Root. Is that normal behavior?
OK,
This the root of my Data drive. I didn't set or change those permissions myself. It's probably OMV GUI who did it when I first setup OMV. Or maybe a change happened after that. I don't know.
What's the root of data drive supposed to have for permissions?
Even if I create a "crashplan_config" folder on the root of the data drive, with User:dockeruser rwx, Group:users rwx Others:r-x, and I tell Docker to save the config over there, Crashplan docker doesn't show me the login page.
Weird... when I create new users, they've always been assigned incrementally from 1000... so for me to get to 2028, I'd have to have over 1k users (misspoke on the 2k, but the point still stands)
The fact it works on the home directory, but not the data drive... makes me suspect there is a permission issue.
Is your Home directory on the Data drive? Otherwise if you have a small OS drive, you may fill it up quickly.
Yes I guess it's weird.
How do I check for permission issues exactly?
My Home directory is on the the OS drive, which is 250GB (98% free).
Here's the permissions for my main Data drive:
Everytime I create a new shared folder from OMV GUI on that drive, the owner is always root rwe, Group: users rwe, Others: rw.
OK I've managed to make it work like this:
version: "2"
services:
crashplan-pro:
hostname: docker-crashplan-OMV
container_name: crashplan-pro
image: jlesage/crashplan-pro
environment:
- "USER_ID=2028"
- "GROUP_ID=100"
ports:
- "5800:5800"
volumes:
- "/home/dockeruser/containerdata/CrashplanPro:/config"
- "/srv/dev-disk-by-label-NVMe500GB:/storage:ro"
Alles anzeigen
I can absolutely live with this.
I thinks it's weird though, that I can store the config in the Home folder but not on one of the storage drives. Don't you?
The PUID looks weird as well. I guess it's possible, but most servers would not hit that number, until they had over 2k users (which I'm assuming is not your case)
Hi KM0201,
I don't have hundreds or thousands of users, but that's the User ID I get:
$ id dockeruser
uid=2028(dockeruser) gid=100(users) groups=100(users),115(ssh),1005(Scan2Folder),1006(dockergroup)
What does not work? Which error do you get?
I don't get the CrashPlan login screen. If I look at the log, it's stuck on :
[CrashPlanEngine] starting...,
[CrashPlanEngine] starting...,
[CrashPlanEngine] starting...,
Here's the full log:
21/02/2021 17:20:36 rootwin: 0x43 reswin: 0x200001 dpy: 0x5a6dea00
21/02/2021 17:20:36
21/02/2021 17:20:36 ------------------ USEFUL INFORMATION ------------------
21/02/2021 17:20:36 X DAMAGE available on display, using it for polling hints.
21/02/2021 17:20:36 To disable this behavior use: '-noxdamage'
21/02/2021 17:20:36
21/02/2021 17:20:36 Most compositing window managers like 'compiz' or 'beryl'
21/02/2021 17:20:36 cause X DAMAGE to fail, and so you may not see any screen
21/02/2021 17:20:36 updates via VNC. Either disable 'compiz' (recommended) or
21/02/2021 17:20:36 supply the x11vnc '-noxdamage' command line option.
21/02/2021 17:20:36 X COMPOSITE available on display, using it for window polling.
21/02/2021 17:20:36 To disable this behavior use: '-noxcomposite'
21/02/2021 17:20:36
21/02/2021 17:20:36 Wireframing: -wireframe mode is in effect for window moves.
21/02/2021 17:20:36 If this yields undesired behavior (poor response, painting
21/02/2021 17:20:36 errors, etc) it may be disabled:
21/02/2021 17:20:36 - use '-nowf' to disable wireframing completely.
21/02/2021 17:20:36 - use '-nowcr' to disable the Copy Rectangle after the
21/02/2021 17:20:36 moved window is released in the new position.
21/02/2021 17:20:36 Also see the -help entry for tuning parameters.
21/02/2021 17:20:36 You can press 3 Alt_L's (Left "Alt" key) in a row to
21/02/2021 17:20:36 repaint the screen, also see the -fixscreen option for
21/02/2021 17:20:36 periodic repaints.
21/02/2021 17:20:36 GrabServer control via XTEST.
21/02/2021 17:20:36
21/02/2021 17:20:36 Scroll Detection: -scrollcopyrect mode is in effect to
21/02/2021 17:20:36 use RECORD extension to try to detect scrolling windows
21/02/2021 17:20:36 (induced by either user keystroke or mouse input).
21/02/2021 17:20:36 If this yields undesired behavior (poor response, painting
21/02/2021 17:20:36 errors, etc) it may be disabled via: '-noscr'
21/02/2021 17:20:36 Also see the -help entry for tuning parameters.
21/02/2021 17:20:36 You can press 3 Alt_L's (Left "Alt" key) in a row to
21/02/2021 17:20:36 repaint the screen, also see the -fixscreen option for
21/02/2021 17:20:36 periodic repaints.
21/02/2021 17:20:36
21/02/2021 17:20:36 XKEYBOARD: number of keysyms per keycode 7 is greater
21/02/2021 17:20:36 than 4 and 51 keysyms are mapped above 4.
21/02/2021 17:20:36 Automatically switching to -xkb mode.
21/02/2021 17:20:36 If this makes the key mapping worse you can
21/02/2021 17:20:36 disable it with the "-noxkb" option.
21/02/2021 17:20:36 Also, remember "-remap DEAD" for accenting characters.
21/02/2021 17:20:36
21/02/2021 17:20:36 X FBPM extension not supported.
21/02/2021 17:20:36 X display is not capable of DPMS.
21/02/2021 17:20:36 --------------------------------------------------------
21/02/2021 17:20:36
21/02/2021 17:20:36 Default visual ID: 0x21
21/02/2021 17:20:36 Read initial data from X display into framebuffer.
21/02/2021 17:20:36 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/5120
21/02/2021 17:20:36
21/02/2021 17:20:36 X display :0 is 32bpp depth=24 true color
21/02/2021 17:20:36
21/02/2021 17:20:36 Listening for VNC connections on TCP port 5900
21/02/2021 17:20:36
21/02/2021 17:20:36 Xinerama is present and active (e.g. multi-head).
21/02/2021 17:20:36 Xinerama: number of sub-screens: 1
21/02/2021 17:20:36 Xinerama: no blackouts needed (only one sub-screen)
21/02/2021 17:20:36
21/02/2021 17:20:36 fb read rate: 1324 MB/sec
21/02/2021 17:20:36 fast read: reset -wait ms to: 10
21/02/2021 17:20:36 fast read: reset -defer ms to: 10
21/02/2021 17:20:36 The X server says there are 10 mouse buttons.
21/02/2021 17:20:36 screen setup finished.
21/02/2021 17:20:36
The VNC desktop is: docker-crashplan-OMV:0
0
******************************************************************************
Have you tried the x11vnc '-ncache' VNC client-side pixel caching feature yet?
The scheme stores pixel data offscreen on the VNC viewer side for faster
retrieval. It should work with any VNC viewer. Try it by running:
x11vnc -ncache 10 ...
One can also add -ncache_cr for smooth 'copyrect' window motion.
More info: http://www.karlrunge.com/x11vnc/faq.html#faq-client-caching
[CrashPlanEngine] starting...
[services.d] starting certsmonitor...
[services.d] starting statusmonitor...
[services.d] starting app...
[app] starting CrashPlan for Small Business...
[certsmonitor] disabling service: secure connection not enabled.
[statusmonitor] starting...
[services.d] done.
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
[CrashPlanEngine] starting...
I've also tried to save the config on another drive:
volumes:
- "/srv/dev-disk-by-label-SATA1TB/CrashplanPro_Docker:/config"
- "/srv/dev-disk-by-label-NVMe500GB:/storage"
CrashPlan still not starting.
Hi macom,
Tried that and it didn't work. User 2028 is "dockeruser".
version: "2"
services:
crashplan-pro:
hostname: docker-crashplan-OMV
container_name: crashplan-pro
image: jlesage/crashplan-pro
environment:
- "USER_ID=2028"
- "GROUP_ID=100"
ports:
- "5800:5800"
volumes:
- "/srv/dev-disk-by-label-NVMe500GB/CrashplanPro_Docker:/config"
- "/srv/dev-disk-by-label-NVMe500GB:/storage"
Alles anzeigen
The folder /srv/dev-disk-by-label-NVMe500GB/CrashplanPro_Docker was created by the docker. Here's what the permissions look like:
Hi there,
I was having some hard time creating a CrashPlan Pro docker. CrashPlan would start. I've troubleshooted and found that if I didn't specify any Volumes in the Compose file, CrashPlan would start OK. Good.
Then I've tried specifying a storage volume. It works. Crashplan starts. It created it's own config folder here by itself:
/var/lib/docker/volumes/4345af57db0eb193671b1872ec653b97e1d553332ca0c8460019a6bb01ab26de/_data
But If I try to specify the /config volume, CrashPlan doesn't start.
So this works:
version: "2"
services:
crashplan-pro:
hostname: docker-crashplan-OMV
container_name: crashplan-pro
image: jlesage/crashplan-pro
environment:
- "USER_ID=2028"
- "GROUP_ID=100"
ports:
- "5800:5800"
volumes:
- "/srv/dev-disk-by-label-NVMe500GB:/storage"
Alles anzeigen
But this doesn't work (only difference is the additional volume):
version: "2"
services:
crashplan-pro:
hostname: docker-crashplan-OMV
container_name: crashplan-pro
image: jlesage/crashplan-pro
environment:
- "USER_ID=2028"
- "GROUP_ID=100"
ports:
- "5800:5800"
volumes:
- "/srv/dev-disk-by-label-NVMe500GB:/storage"
- "/srv/dev-disk-by-label-NVMe500GB/Settings/CrashplanPro_Docker:/config"
Alles anzeigen
I didn't create the ../Settings/CrashplanPro_Docker folder at first. I wanted docker to create it by itself. Which it did. But CrashPlan doesn't want to start.
At the end of the log, we see:
[CrashPlanEngine] starting...,
[CrashPlanEngine] starting...,
[CrashPlanEngine] starting...,
[CrashPlanEngine] starting...,
[CrashPlanEngine] starting...,
[CrashPlanEngine] starting...,
Any ideas why this wouldn't work?
Is there a way (command) I could do to reset the drive that's not working?