Seite wählen

NETWAYS Blog

OSCamp on Bareos: Submit your Paper!

The title of this year’s Open Source Camp (OSCamp) tells it all: We want your backup stories! And ideally you tell them on stage. This time we focus on the Open Source backup software Bareos. Together with the Bareos company we invite you to share your expertise.

Call for Papers open

Call for Papers is open until March 30, 2020! Share your technical insights into Bareos and offer administrators new impulses for data backup, archiving and recovery. Each presentation is scheduled for 45 minutes, including a 5 to 10-minute Q&A session. Submit your paper at opensourcecamp.de!

The OSCamp on Bareos is where the community, Bareos users and developers meet – it’s an opportunity to talk to like-minded people and share expertise – as a speaker on stage, or as attendee during discussions and breaks.

What is OSCamp all about?

Open Source Camp is a conference format dedicated to changing Open Source projects and products and of course their communities.

The one-day event comprises expert presentations and tutorials on technical backgrounds, insights into the latest developments, how-tos, as well as future trends and perspectives. Focusing on advanced topics, the international addresses experienced administrators and systems engineers.

Get in touch with the Open Source enthusiasts behind the presented projects. Learn new features and techniques, benefit from their extensive know-how and get up-dated on the latest developments.

About Bareos

Bareos (Backup Archiving Recovery Open Sourced) provides an enterprise-level open source platform that preserves, archives and restores data from all major operating systems. The cross-network software protects your most critical data on-premises and in the cloud, including Enterprise Storage Systems.

Bareos offers NDMP support, LTO hardware encryption, bandwidth management, and a sophisticated scheduler that increases the level of automation.

Following stackconf

OSCamp #5 on Bareos takes place directly after stackconf, on June 19, 2020, in Berlin. More about stackconf at stackconf.eu! This is your chance to join two outstanding Open Source events in one week!

More information and tickets at opensourcecamp.de.

 

NWS OpenStack – automatisierte Snapshots

Unser Ziel war und ist es, eine Plattform zu schaffen, die sehr hohe Flexibilität, Sicherheit und Komfort bietet. Unsere Kunden sollen in eigenen, isolierten Projekten ihrer Kreativität freien Lauf lassen und nahezu uneingeschränkt sein, ohne sich um essenzielle Dinge Gedanken machen zu müssen.

In genau diesem Zuge, haben wir diese Woche ein neues Feature für unsere OpenStack Cloud veröffentlicht – automatisierte Snapshots für virtuelle Maschinen und Volumes! Mit diesem neuen Feature können sich unsere „IaaS“ (Infrastructure as a Service) Kunden zurücklehnen, entspannen und die Verantwortung der zuverlässigen Sicherung an uns abgeben. Wir stellen sicher, dass ausgewählte Instanzen ordnungsgemäß gesichert werden und dieser Prozess überwacht wird.

Doch wie genau funktioniert das nun? Wir haben in unserer Plattform einen Menüpunkt eingebaut, der als Schaltzentrale fungiert. Eingesehen werden kann dieser von jedem Nutzer in der Übersicht seiner OpenStack Instanz. Es werden hier alle VMs sowie Volumes aufgelistet und gegebenenfalls mit Notizen versehen. Beispielsweise in welcher VM ein Volume unter welchem Pfad eingehängt ist.

In dieser Liste kann nach belieben, durch setzen eines Hakens, der Sicherungsprozess aktiviert oder deaktiviert werden.
Neben dem Erstellen von Backups werden nach einer gewissen Retention, Snapshots natürlich auch vollkommen automatisch wieder gelöscht. Per Default alle Sicherungen, welche älter als 7 Tage sind.

Eine Übersicht über die aktuellen Sicherungen gibt es im OpenStack selbst:
Compute -> Images / Volumes -> Snapshots 

Erweiterungen zu dieser Sicht sind geplant. Ebenso weitere neue spannende Features, welche aktuell noch in der Entwicklung sind.
Wir haben zum Snapshot/Backup Release auf unserem Twitter Account ein kurzes Video mit einer Live Demo dazu für euch vorbereitet. Lasst uns auf Twitter gerne wissen, was ihr davon haltet!

Noch kein NWS IaaS Kunde? – Hier geht’s zu unserer Platform

New feature for our @OpenStack NWS released today! You can now configure your backups for volumes and instances – just by checking them in your NWS interface! Check this out! For more informations stay tuned #IaaS #SaaS #devops #backup

>> https://t.co/iDInYc1pxj << pic.twitter.com/nZrg8B5x55

— NETWAYS Web Services (@NetwaysCloud) January 28, 2019

Ceph Mimic | Using loop devices as OSD

For quite some time we have been using ceph-deploy to deploy OSD in folders during the Ceph trainings held by Netways. This worked perfectly with jewel, but newer versions don’t allow this behaviour anymore.
There are several reasons for this, however, as we have a quite regulated setup for our training notebooks, we had to come up with some kind of workaround. This approach is, while working fine in our training setup, not recommended for production!
The following steps apply to a current CentOS 7 system.
As stated before, we will deploy an OSD on a block device. Though you could use a separate partition for this, we will use a loop device. For this, the first step is to create a file:
For this, create an OSD directory
 
[bash]$ mkdir -p /home/training/my-cluster/osd-$HOSTNAME
$ cd /home/training/my-cluster/osd-$HOSTNAME/[/bash]
in this folder, create a file for later use
[bash]
$ fallocate -l 30G 30GB.img[/bash]
test it
[bash]
# losetup -l -P /dev/loop1 &quot;/home/training/my-cluster/osd-$HOSTNAME/30GB.img&quot;
# wipefs -a /dev/loop1
# lsblk
[/bash]
This should then display your new loopdevice.
As loop devices are not reboot safe, you need to go some steps further. If you like to use rc.local for this, you’re free to do so.
We’re going to create a service, which will essentially execute the prior mentioned losetup command. For this, we need a script with the command and a .service file, which will execute the script:
[bash]
rebloop.sh
#!/bin/bash
sudo losetup -l -P /dev/loop1 &quot;/home/training/my-cluster/osd-$HOSTNAME/30GB.img&quot;
[/bash]
and the service file:
[bash]
rebloop.service
[Unit]
Description=Reattach loop device after reboot
[Service]
Type=simple
ExecStart=/bin/bash /usr/bin/rebloop.sh
[Install]
WantedBy=multi-user.target
[/bash]
These files have to be executable and be copied to the correct folders. Afterwards, the service must be enabled and can be started.
[bash]
# chmod +x rebloop.*
# cp rebloop.sh /usr/bin/rebloop.sh
# cp rebloop.service /etc/systemd/system
# systemctl enable rebloop.service
# systemctl start rebloop.service
[/bash]
Ceph, however, will still not want to create an OSD on this device, instead give you following error message:
[bash]
–&gt; RuntimeError: Cannot use device (/dev/mapper/&lt;name&gt;). A vg/lv path or an existing device is needed [/bash]
You have to make changes to /usr/lib/python2.7/site-packages/ceph_volume/util/disk.py on the OSD host:
in line 201, add „or TYPE==’loop'“:
[python]# use lsblk first, fall back to using stat
TYPE = lsblk(dev).get(‚TYPE‘)
if TYPE:
return TYPE == ‚disk‘ or TYPE == ‚loop'[/python]
and in line 286, change the „skip_loop“ switch from „True“ to „False“:
[python] def get_block_devs(sys_block_path=&quot;/sys/block&quot;, skip_loop=False): [/python]
For testing purposes, simply reboot your system and verify if the loop device gets reattached correctly.
If yes, you can deploy an OSD. We’re using ceph-deploy here:
[bash]$ ceph-deploy osd create –data /dev/loop1 $HOSTNAME[/bash]
When the command was successfully executed on your hosts, you can create your first pool
[bash]# ceph osd pool create rbd 100 100 replicated[/bash]
examine ceph status
[bash]# ceph status[/bash]
tag the pool with an application
[bash]# ceph osd pool application enable rbd rbd[/bash]
As you can see, there are quite some changes to be made, and each of it is failure-prone.
Best practice is to simply use a real block device and for production you really should stick to this.
If, however, there are certain needs to be fulfilled, ceph can be convinced to comply.
 
Sources:
http://tracker.ceph.com/issues/36603
https://tracker.ceph.com/issues/23337
https://github.com/NETWAYS/ceph-training
 
 
 

Tim Albert
Tim Albert
Senior Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...

Lokale Time Machine Snapshots blockieren Speicherplatz

Kürzlich hatte ich den Plan, ein ca. 100GB iPhone Backup zwischenzeitlich auf dem Mac anzufertigen. Meinem Plan stand nach einem kurzen Blick auf den freien Diskspace des Finders eigentlich nichts im Wege, denn dieser zeigte noch 120 GB freien Speicherplatz an. Nachdem sich das Backup aber mit einem bisher unbekannten Fehler verabschiedete, machte ich mich einmal auf die Suche, was mein Mac denn so eigentlich macht.
Ein Kurzer Blick im Terminal bestätigte mir allerdings viel weniger freien Platz auf der Platte, als der Finder es tat. So waren hier nur noch 55 GB frei. Wie kann das sein?
Zunächst einmal öffnet ihr euer Terminal im Mac und gebt folgendes Kommando ein

df -h

Der Mac zeigt nun in aller Regel in der ersten Zeile die Informationen der Mac-Festplatte (Gegenkontrolle Anhand der Size-Spalte) an. In der Spalte Available steht der noch zur Verfügung stehende Speicherplatz. Sollten sich diese Werte im Finder und im Terminal erheblich unterscheiden, macht es Sinn, die Snapshots unter die Lupe zu nehmen.
Warum Snapshots?
Sollte das Time Machine Backup Volume (z. B. wenn man im Urlaub ist) nicht verfügbar sein, fertigt der Mac lokale Snapshots an. Ein solcher Snapshot schützt zwar nicht vor Datenverlust bei einem Hardwareschaden, wohl aber bei unbeabsichtigten Löschen – also die haben schon Ihre Daseinsberechtigung und fertigen zuverlässig auch ohne Backupvolume im Hintergrund eine Art Sicherung an. Normaler Weise gibt der Mac nach und nach die Snapshots frei, wenn er merkt, dass der Platz benötigt wird. Das ist wahrscheinlich auch der Grund, warum der Finder die Snapshots von der Kalkulation des freien Speicherplatzes excludiert.
Habe ich auch Snapshots?
Sofern ein Time Machine Backup läuft, wird diese Funktion aktiviert. Allerdings tritt sie nur in Kraft, wenn das Backup-Volume nicht verfügbar ist. Am besten prüft man das kurz über das Mac-Terminal mittels Eingabe des folgenden Kommandos. Es listet alle vorhandenen Snapshots der Primärplatte auf.

tmutil listlocalsnapshots /

Möchte man nun einmal solche Snapshots entsorgen, so lässt sich das mit folgendem Kommando erledigen

sudo tmutil thinLocalSnapshots / 10000000000 4

Kurze Erklärung hierzu: / Bezieht sich wieder auf das soeben ermittelte Volume (also die primäre Festplatte, das braucht man in aller Regel nicht ändern), 10000000000 bezieht sich auf den „purgeamount“ also die Menge, in diesem Beispiel sind das 10 GB. Um mehr freizugeben, Zahl auf beliebigen Wert in Byte erhöhen, oder Kommando mehrfach ausführen. Die 4 steht für die „urgency“, also die Dringlichkeit. 1 ist hier die höchste, aber 4 reicht eigentlich auch zum Löschen.
Nachhaltig verhindern, lassen sich lokale Snapshots auf den Apple-Geräten mit folgendem Kommando:

sudo tmutil disablelocal

Alternativ Time Machine nicht mehr nutzen, oder dafür sorgen, dass die Backupvolumes immer verfügbar sind.

Why you shouldn't miss OSBConf 2018 – #6

Being too busy to worry about backup, is like being too busy driving a car to put on the seatbelt. — T.E. Ronneberg
Don’t miss the latest Backup Solutions! This year’s conference program includes wellknown Backup specialists and their latest findings, such as:
Toshaan Bharvani (VanTosh): „Schroedingers Backup“
Gratien D’haese (IT3 Consultants): „Relax-and-Recover Automated Testing with Bareos“
Daniel Neuberger (NETWAYS): „Restore and Backup Elasticsearch Indices“
Maik Außendorf & Philipp Storz (Bareos): „What’s new in Bareos 18“
To see the whole conference program visit: osbconf.org
 
In 2017 Josef Weingand talked about why Tape is essential for your Backup environment!
Check out his talk!
 

YouTube player