Beiträge von erik

I like rsnapshot, together with remote-shares it does what I want. So my questions are a summary of my experience the last eight weeks, because I like to understand how it is going and to avoide beginner faults.

remote-shares - Was a recommendation of subzero and you. I put in on samba, for some reason I doesn't understand, I was unable to switch on nfs on the same hardware setup. But as samba worked I did not further investigate in the nfs-issue .
Does it make sense to go for nfs instead of samba? What would be the benefits?

Sequence and manual starting the job is nice when initially filling. Its hard to figure out rsnapshot in the process list, as it starts rsync the same time.

"gui blocked" - When starting rsnapshop manually from the gui, a window pops up with two options "Start" and "Stop". After manual start the gui waits for finished or manual "Stop". Anything else of omv-gui is left behind unreachable.

Even with the wrong permissions of remote-shares, the copy is running with all files. Again, would nfs help to avoid these permission warnings?

Samba supports hardlinks, otherwise the utilization of the disk would blow up. Time-Backup was way faster, maybe they use some kind of database in the back what speeds up. But if there isn't a switch "slow-medium-fast", I did not find yet, I can live with that.

rsync after snapshot whould generate two copies of the original. rsnapshot on remote-share gives one incremental copy on a seperate server. That's better for me.

The problem with the process list, email notifications aso is not lack of information. It is too much information, where the important messages are difficult to find.

As you write " I have used it for a long time. Works great." - what are you using now?

I wouldn't share the backup-folder via samba to secure it from direct access.
If needed only as read-only. Too much ransom-trojans actually.

Sorry guys for having again questions about rsnapshot.

I have 7 folders on OMV, so I set up 7 tasks for rsnapshot. Target is a second server with two backup-folders mapped via remote-shares. The jobs are running daily - so far ok, it works as it should. Scheduled time is 20:00 (as in /etc/cron.d/openmediavault-rsnapshot defined).

Here are my questions:

- Where can I see the jobs on the CLI, where could I change the sequence of the jobs. It seems the sequence is defined by the order of set up?

- Where can I see in the GUI whether a job is running or has been finished?

- When I start a job manually from the GUI, a window pops up with "start" and and actual messages, but my GUI is blocked. How can this be changed?

- With manually start, sometimes statement like this occur:
rsync: chown "/media/9475796c-....-3d74fa16dca0/remote-shares/backup/DATEN4000/video/daily.0/SAT/Filme/Johnny English - Jetzt erst recht.eit" failed: Permission denied (13)
What does this mean? Why is rsnapshot (rsync) going to change the owner? I thought rsnapshot itself has admin rights and can copy everything.

- Why do the rsnapshot-jobs take so long? Even without changes, a new copy of 500 GiB (daily.o --> daily.1) takes approx. 1 hour. Both server on the same switch with Gigabit.

- In case the backup server is not present, remote-shares is unable to map, but rnapshots nevertheless starts a new backup on place of the designated (empty) mapping folder, what blows up my internal disk. How can this be prevented?

- And last but not least, is there a better way to make daily, scheduled, differential backups? Sorry, I am spoiled by Time-Backup (Synology), that is fast, reliable and gives a clear statement via mail whether the backup was successful.

I also have a "bad" drive:

seems due to Available_Reserved_Space and Media_Wearout_Indicator.
After 5000 h of utilization and total host writes of 4,2 TB, I am neither going to scrap it nor to make a RMA.

To me the indicator is false positive.
To check this, I passed this to Chrystal Disk Info, which said: Good(99%).

Scheint eher ein Netzwerk- als ein Serverproblem zu sein.

1.) mit dem Installations-ISO file (also von CD-Rom oder bootfähigem USB-Stick) sollte sich Grub installieren lassen. Wenn nicht stimmt was nicht mit der Reihenfolge, wie die Installtionsroutine die Laufwerke sieht, also wie sie versucht, Grub auf den Stick zu schreiben.
Abhilfe: Bei der Installation sollten nur System-Laufwerk und Stick angeschlossen sein, und wenn die Routine zickt, kurz vor Schreiben des Grubs den Stick rausziehen.
Aber wenn bei Dir LILO funktioniert, ok.

2.) Das muss am Router eingestellt werden. Stichworte sind Portforwarding und Dienste wie dyndns, no-ip.biz oder andere. Die bessere Alternative ist, den externen Rechner per VPN an den Router zu binden. VPN kann auch auf den OMV-Server installiert werden, aber die Konfiguration am Router ist meistens einfacher.

3.) SSH musst Du in OMV explizit aktivieren, danach kannst Du darauf im internen Netz mit Programmen wie Putty mit der lokalen IP zugreifen (wenn das läuft, direkt den MC auf der Kommandozeile installieren (apt-get install mc)).
Externer Zugriff mit SSh ist dann ähnlich wie unter 2)

I agree, the data is important and backups are mandatory.

Actual I have no backup of system, as I guess that installation from scratch is faster than dealing with old system-copies. But the more you play with plugins, container and virtual machines, the more demand is to save the setup.

Zitat von schpongo

But what are potential downsides to storing data on the same drive the OS is installed on (two partitions).
Some people advise against this practice and I would like to know why, so I can make my own "educated" decision.

The only downside I see is, that after installation of OMV, you have to connect your SSD to another Linux-OS to re-partition it. After this there are no further obstacles and you can use this additional partition as data. I did this for testing (re-sizing system to 16 GiB) and it works flawless.

Some people just re-map the free space of system to data by means of symbolic links.
This also works, but there is always danger, that data is eating up the space of system.

To my understanding, the 2-partition solution should be safe.

Zitat von WastlJ

If you have a spare Sata-Port or a usb to sata adapter, a HDD or SSD is better than a USB Stick. However, since we have the flashmemory plugin like erik said, you can use USB Sticks, too.

I had serious problems with an USA-Sata-adapter, bought for this purposes. Anytime I tried to switch on Smart-reading, the GUI froze. Another side effect, setting of time or time zone was impossible. The adapter itself was ok, transfer speed and stability were good.
Nice welcome for OMV-beginner!
Then I switched to USB-flash stick as system and everything worked.

Funny, for testing I put the same SSD with the old 'faulty' installation in a 2,5"-external case and plugged this to internal USB, this worked flawless. But as the stick still I arrived, I stayed with this solution. So USB-Sata may work, but this can cause strange problems.

1a) USB Stick with SLC (single level cell), not cheaper than a small SSD
1b) Standard quality stick with MLC (the normal ones), to get it reliable, the flashmemory plugin is mandatory.

2) OMV out of the box takes the whole drive. It is possible to repartion (GPArted) the SSD after installation, leaving at least 8 GB of system and an additional partition with the remaining space for data.

Option 1 and using the SSD straight for data seems to be easier, but both ways are no rocket science.

AS GParted Live also comes with the backup plugin, would it be possible to use GParted to clone the system drive (ok its headless, two times a year one have to connect keyboard and monitor)?

GParted has a GUI and can be utilized by normal home users. Clonezilla is fine for software engineers, but for everyone using this tool every six month, it is a pain in...

Since I am using OMV, backup and restore is a neverending issue. I like the Landrover feeling of OMV, but sometimes the convenience of an SUV would be appreciated.

Sounds like a problem, one guy here in Germany had recently. During the installation, you have to choose a mirror server, from where actual updates for debian are pulled.

So I went for this files:
openmediavault_2.1_amd64.iso
from sourceforge.net/projects/openmediavault/files/

copy to bootable Flash-drive (USB) or just easier, burn it on CD-Rom if your Dell has CD-Rom and let it run.
After this:

openmediavault-omvextrasorg_latest_all.deb
from omv-extras.org/simple/index.php?id=how-to-install-omv-extras-plugin
to be installed inside OMV.

Whats wrong with Grub?
OM-installation will copy itself on your 160GB-hdd and sets all parameter for Grub. Please be aware that this hdd is only for system, you need additional hdd's for data. (there are tricks to utilize free space on system, but I wouldn't do it in the beginning).

If you are installing with Flash-drive and problems with Grub remain, you can do the following:
Do the installation until the routine wants to install Grub (very late). At this moment pull out the stick, so that the hdd is the only drive in your computer. Normally this workaround helps to write Grub on the correct drive.

erik

Thanks for the hint. I have tried out all of these options.

I guess the error is in the way the container data path are linked to the host, as the alternative approach with nginx worked (but causes other problems to me). So I asked for a template on working docker settings.

Just the plugin or the whole OMV from scratch?

Purging (for beginners) always incorporates the danger to wipe the dependencies and to blame the system.
And even as it works, it has no learning effect.

So I prefer to test out new thinks in a VM, but sometimes ok in VM, anyway causing problems on bare metal.

Yes!

Normally first call of OC sets up the database (user and database name) in mySQL by means of the root@localhost (password) access, but starting OC as a docker container, I am just getting error codes from mySQL.

Zitat von omavoss

kann das daran liegen, das du nicht das Passwort von dem Datenbank-Benutzer -den du vorher anlegen musstest- eingibst, sondern das Passwort um als Admin in mysql zu kommen?

Meine Vorgehensweise (mal in Ebenen ausgedrückt):

Ebene 1:
Installation on OMV, darin webGUI admin mit zugehörigem admin Passwort zum Anmelden an die Gui.

Ebene 2:
Installation des mySQL-Plugins, erzeugt den root (genau genommen root@localhost, root@127.0.0.1,...) mit zugehörigem Passwort.
Vom Plugin aus kann man über Fenster oder neuen Tab in phpMyAdmin mit o.g. root-Zugang erreichen. Hier sind auch alle Datenbanken sichtbar (bis hierhin noch nichts von OC)

Ebene 3:
Installation von OC nach Howto mit nginx usw,
Erster Start,
Festlegen des admin und eigenem Passwort,
Angabe der Datenbank (mySQL) und des Nutzers root@localhost nebst entsprechendem Passwort von root.
Angabe eines Datenbanknamens (z.B. "owncloud")
Dabei wird in mySQL die Datenbank "owncloud" und der Nutzer (von admin von owncloud) als oc_admin angelegt.
Das kann man in phpMyAdmin überprüfen.

Beim nächsten Aufruf von OC mit dem angelegten admin und passwort passiert nichts, setzt man das oc_admin-passwort nochmal in phpMyAdmin, schmiert OC beim nächsten Aufruf ab.

Ich habe bisher in mySQL keine Datenbank oder Nutzer vor Erstaufruf von Owncloud angelegt und denke das ist auch nicht nötig da Owncloud das selber macht.

In der VM zum Testen haben alle admins und roots eh das gleiche Passwort um Verwechslungen auszuschließen.

Es gibt ein sehr gutes Howto der alternativen Lösung (Owncloud-8-and-MySQL-alternative-approach).
Leider hat es bei mir in der VM nicht funktioniert, möglicherweise da der Ursprungspost 2 Jahre alt ist und sich seither was geändert haben könnte. Die 12 Seiten Folgeposts sind relativ schwer zu lesen.

Owncloud/Docker hat sofort funktioniert. Ich muss aber noch über die Klippe, bei der Initialisierung von OC die entsprechenden Datenbanken in mySQL zu setzen. Bisher nur Fehlermeldungen, wahrscheinlich stimmen die Rechtevergaben bzw. die Ordnerstrukturen im Setup des Containers nicht.

Deshalb habe ich parallel gefragt, ob das jemand in dieser Form am Laufen hat.

Wie ist denn jetzt der aktuelle stand bezüglich Owncloud?

Bisher bin ich dreimal strecken gebleiben:

Owncloud als Plugin:
Nur Version 6.x, langsam da nur SQLite, Update mehr oder weniger nicht möglich. Läuft, aber nicht praktikabel.
Wenn man dieses Plugin nicht weiterentwickelt und es in dieser Form nur wenig Nutzen hat, sollte man es zurückziehen.

Owncloud als Direktinstallation mit nginx (Owncloud-8-and-MySQL-alternative-approach)
In VM gestestet: Installation hat im Prinzip funktioniert, nach erstem Start wurde aber das Admin-Paßwort nicht akzeptiert. Dieses konnte auf der mySQl-Managementseite gesetzt werden. Nach Aufruf von OC hing sich das System auf.
Der Thread hierzu ist mittlerweile 2 Jahre alt und 12 Seiten lang. Wahrscheinlich steht sogar irgendwo eine Lösung drin. Die muss man dann wie die Nadel im Heuhaufen suchen.
Eine Aktualisierugn des ansonsten sehr guten Howto mit Zusammenfassen der Erkenntnisse wäre hier eine echte Bereicherung.

Owncloud im Docker-Plugin
Eigentlich eine elegante Lösung. Der Container funktioniert und OC läßt sich auch mit der eigenen (langsamen) SQLite-Datenbank starten und betreiben.
An der Initialisierung mit mySQL bin ich aber bisher gescheitert.
Also so auch nicht direkt praktikabel.

Was einwandfrei geht und easy zu installieren war, ist DS-Cloud unter XPEnolgy in einer virtuellen Box unter OMV.
Aber das kanns doch nicht sein!

Is anybody running an actual owncloud (8.x) inside a docker container (docker-plugin) connected to the mysql-plugin?
Would be nice to get a template for the docker settings of the owncloud-container for this standard configuration.

Thanks in advance.

no answers.
In the meantime a full purge of mysql and a clean new install of the mysql-plugin helped me out. I do not know whether everything is correct, sticking with owncloud doesn't work.

I have two Synology's, one series 09, sticked with DSM 4, never got DSM 5, but still doing its job very well as internal backup.
The second one, series 12 became too small. If I'd go for a Synology with the performance of an Hp Gen8 Mikroserver with OMV and 4 bays, the price would be three times as high.

So in the unlikely event that everybody at OMV stops his (her) work, I would be happy with the latest available version, getting further Debian updates for a long time, just lacking newer features. And if I'd be missing some of the newer features, there would be always an alternative.
But that's theoretical, actual for me no need to have heavy thoughts about this.