<div dir="ltr">Thanks for this, it's better than what we had before.<div><br></div><div>Jake</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020 at 5:24 PM tranxene50 <<a href="mailto:tranxene50@openvz-diff-backups.fr">tranxene50@openvz-diff-backups.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
Here is the first part of a quick "survival" guide in order to start off <br>
on the right foot with openvz-diff-backups (OVZDB for short).<br>
<br>
Please, be aware that English is not my native language. So, if you see <br>
something weird, please quote the sentence and correct it.<br>
<br>
Equally, if something is not clear, quote and ask: I will try to answer <br>
the best as I can.<br>
<br>
# ---------------------<br>
<br>
Firstly, you need to be aware that OVZDB use three <br>
"hosts/locations/storages" and "navigate" through them:<br>
<br>
# ---------------------<br>
<br>
- SOURCE : "host" where OVZDB is installed<br>
<br>
Most of the time, this is the server on which OpenVZ is running the <br>
containers you want to backup.<br>
<br>
But it can be any *nix system (with Bash/OpenSSH/rsync) in order to <br>
replicate (upload or download) backups between REMOTE and MASTER.<br>
<br>
Everything works over SSH as follow: SOURCE -> SSH key 1 -> MASTER -> <br>
SSH key 2 -> REMOTE<br>
<br>
# ---------------------<br>
<br>
- MASTER : *mandatory* "host" where backups are stored (copy A)<br>
<br>
Ideally, MASTER is a dedicated server/VPS/other because OVZDB relies on <br>
IOPS and, the more RAM you will have to cache dentries and inodes, the <br>
faster OVZDB will be.<br>
<br>
However, by default, backups are stored on the the same server <br>
(MASTER_SSH_PATH="root@localhost:/home/backup/openvz-diff-backups").<br>
<br>
This is useful if you want to test ASAP or if you have a secondary drive <br>
where backups can be stored (ex: sda for OpenVZ, sdb for backups).<br>
<br>
In this case, SOURCE will communicate with MASTER (both being on the <br>
same server) using SSH through localhost: as soon as "ssh -p 22 <br>
<a href="mailto:root@127.0.0.1" target="_blank">root@127.0.0.1</a>" gives you a shell without asking for a password, you are <br>
done.<br>
<br>
On the contrary, if MASTER is a distant host (recommended), you need to <br>
adjust MASTER_SSH_PATH parameter.<br>
<br>
Ex: <br>
MASTER_SSH_PATH="root@backup.my-server.net:/any-absolute-path-you-want"(trailing <br>
slash is not needed and "<a href="http://backup.my-server.net" rel="noreferrer" target="_blank">backup.my-server.net</a>" will always be resolved <br>
to its IPV4 or IPV6 address)<br>
<br>
If you need to use a SSH port different from 22, please see <br>
MASTER_SSH_OPTIONS parameter in config file (openvz-diff-backups.conf).<br>
<br>
# ---------------------<br>
<br>
- REMOTE : *optional* host where backups are replicated (copy B)<br>
<br>
In order to secure backups, you may want to replicate them, if possible, <br>
in a different geographical location.<br>
<br>
MASTER/REMOTE "hosts" can be anything as long as a *nix system is <br>
present with a shell, OpenSSH (other SSH servers have not been tested <br>
yet) and, the most important, rsync.<br>
<br>
This can be a big fat dedicated server, a large VPS, a medium instance <br>
in the Cloud, a NAS at home or even - if someone is willing to test (I <br>
didn't because mine is too old) - an Android smartphone...<br>
<br>
SOURCE "host" always requires a Bash shell but MASTER/REMOTE "hosts" <br>
only need a shell (sh/dash/ash/etc) and OVZDB can also deal with <br>
"Busybox" instead of using standard Unix tools.<br>
<br>
In short, OVZDB does not care and will run as long as the "host" can <br>
handle it (which can take hours/days on very low-end hardware).<br>
<br>
# ---------------------<br>
<br>
From SOURCE, you can launch any task (more details in part 2):<br>
<br>
- backup task will "convert" containers present on SOURCE into backups <br>
on MASTER<br>
<br>
- restore task will "convert" backups present on MASTER into containers <br>
on SOURCE<br>
<br>
- upload task will replicate backups present on MASTER to REMOTE (push)<br>
<br>
- download task will replicate backups present on REMOTE to MASTER (pull)<br>
<br>
- delete task will remove backups present on MASTER and/or REMOTE(you <br>
choose)<br>
<br>
- destroy task will wipe "cache" present on MASTER and/or REMOTE (more <br>
in part 2 because it is not intuitive)<br>
<br>
- update task will check and/or update OVZDB to its latest version <br>
("one-click" upgrade)<br>
<br>
# ---------------------<br>
<br>
Before going into details about each command, here are some use case <br>
scenarios about backups:<br>
<br>
(to be shorter, I will not talk about migrating IP addresses, adjusting <br>
firewalls, replacing a dedicated server and other things)<br>
<br>
- 1 server<br>
<br>
Your only choice is to store backups on the same server, if possible on <br>
a secondary hard drive or, better, on an external hard drive.<br>
<br>
Long story short, if you are a believer, pray! ^^<br>
<br>
- 2 servers(one for prod, one for backup)<br>
<br>
If you have enough space, store backups on prod server (copy A) and <br>
replicate them (push) on backup server (copy B).<br>
<br>
(or, better, on backup server, replicate backups using "pull" mode: this <br>
is safer because it would require that both server are compromised to <br>
loose all your backups)<br>
<br>
Then, use OVZDB on backup server and restore every container on a daily <br>
basis to speed things in the event of an emergency "switch".<br>
<br>
This way, if prod server crash, you can restore containers on backup <br>
server and, because most files are already synced, you will be online <br>
again quickly.<br>
<br>
- 2 servers(both prod)<br>
<br>
If you have enough space (bis), store backups - of containers of each <br>
prod server - locally (copy A) and replicate them on the other prod <br>
server (copy B).<br>
<br>
(since both servers have root access to each other, using "pull" or <br>
"push" modes are equals: if one server is compromised, you are screwed).<br>
<br>
Or, you can create OpenVZ containers on both servers to restrict access <br>
to backups.<br>
<br>
This requires that prod A have no SSH keys in order to access to prod B <br>
and inversely.<br>
<br>
Prod A will use container A to store its backups (same for prod B with <br>
its container B) and then, you can use "pull" mode.<br>
<br>
Prod B will download backups from "restricted" container A and Prod A <br>
will download backups from "restricted" container B (this way, if a <br>
server is compromised, you still have backups).<br>
<br>
*WARNING: never, ever, store OVZDB backups in a container using Ploop <br>
layout: it will get insanely fat and "ploop balloon discard" won't help <br>
much*<br>
<br>
Instead, use bindfs to mount a directory from the host into the container.<br>
<br>
Then, again on a regular basis, restore containers from prod A on prod B <br>
and - you have guessed - restore containers from prod B on prod A.<br>
<br>
If one server crash, containers from the other server will be almost <br>
ready to ready to start: just one final restore and you are "done".<br>
<br>
- 3 servers(one for prod, one for backup, one for rescue)<br>
<br>
Ideal but may be costly.<br>
<br>
Store backups on backup server (in a different data center) and <br>
replicate them on rescue server (in a different geographical location).<br>
<br>
If backup server can handle the load of prod server, restore containers <br>
regularly on it in order to be ready to "switch" ASAP on it if prod crash.<br>
<br>
Rescue server can use "pull" mode to replicate backups (download): this <br>
way, if prod and backup servers are compromised, you still have backups.<br>
<br>
- 3 servers(two for prod, one for backup)<br>
<br>
If possible, store backups - of containers of each prod server - locally <br>
(copy A) and replicate them on the other server (copy B).<br>
<br>
Then use backup server to "pull" backups (if prod A and B are <br>
compromised, you still have backups).<br>
<br>
Or, but this is highly dangerous, store all backups from prod servers on <br>
backup server (push).<br>
<br>
- 3 servers(all prod)<br>
<br>
See "2 servers(both prod)"<br>
<br>
- 4 servers(3 for prod, one for backup)<br>
<br>
See "3 servers(two for prod, one for backup)"<br>
<br>
- more than 4 servers<br>
<br>
At this point, I assume that you are using XFS or a distributed <br>
filesystem (Ceph?).<br>
<br>
- more than 10 servers<br>
<br>
You know the drill, the only thing to know is that OVZDB needs IOPS and <br>
RAM in order, for the kernel, to cache inodes/entries.<br>
<br>
And, if you have 10 Gbits network cards, consider syncing and <br>
de-duplicating "root.hdd" using brute force. ^^<br>
<br>
# ---------------------<br>
<br>
This is all for today!<br>
<br>
Tomorrow, or later, I will explain each task: <br>
backup/restore/delete/upload/download in more details.<br>
<br>
-- <br>
tranxene50<br>
<a href="mailto:tranxene50@openvz-diff-backups.fr" target="_blank">tranxene50@openvz-diff-backups.fr</a><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@openvz.org" target="_blank">Users@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.openvz.org/mailman/listinfo/users</a><br>
</blockquote></div>