Hello,
wt., 27 wrz 2022 o 22:41 Marco Gaiarin <g...@lilliput.linux.it> napisał(a):
>
> Defining a backup strategy, we are evaluating our previous different
> policies, mostly based on Bacula and rsnapshot.
>
> Bacula here is used with different media (tape, tape library, virtual
> changer with RDX disks, ...) but we are considering for this a 'File'
> storage type.
>
>
> The goal is to have a 'quick and efficient' backup system that have some
> level of history, but minimizing space, and that can be used as a
> 'intermediate' level for subsequent backups (eg, on a tape library).
>
>
> Rsnapshot is very efficient, and even if the data to backup is HUGE, can be
> initialized very easy, simply 'waling' to the data repository, do an
> initial
> rsync on a disks, and then copy that as a startbase for rsnapshot.
> Also, being a folder structure, can be easily put on other media.
>
I'm not familiar with rsnapshot, but I'm curious how you manage rsnapshot
archives on tape libraries which span multiple tape cartridges (other
media)?
>
> Coons are that is very insecure: backup have to be originated by the backup
> server, that need ssh root access to the client, possibly screwing all the
> client (ok, we can think of chrooting something, but...).
>
>
> I'm trying to give a try to bacula with a 'VirtualFull' job, but i'm a bit
> confused... i suppose job consolidation is done on the pool, not on a
> media;
> but if yes, how media get rotated?
>
It is a real data write on media if you use the Community version. It is a
"block reference only" when using BEE with Deduplication Plugin on
supported media (so no tapes).
The main purpose of virtual full is to create "current" Full backup level
based on data already available on backup media without connecting to the
backup client and making network traffic or any load on this client.
It is not meant to minimize archive space. The space required to save your
backups will be the same regardless you execute virtual full or standard
full.
Bacula uses compression and backup levels (incr, diff) as a primary
solution to save backup space. There is a Base Job feature allowing to
implement deduplication on Community version and Block level deduplication
(GED) on BEE.
GED works extremely well. Here you can check stats from my server:
Dedupengine status: "*Dedup*"
DDE: hash_count=443710333 ref_count=4573101154 ref_size=296.9 TB
ref_ratio=10.31 size_ratio=20.18 dde_errors=0
Config: bnum=1476394991 bmin=400000000 bmax=0 mlock_strategy=0 mlocked=0MB
mlock_max=0MB
HolePunching: hole_size=4096 KB
Containers: chunk_allocated=809438458 chunk_used=443710250
disk_space_allocated=25.44 TB disk_space_used=14.71 TB
containers_errors=0
> Also, there's some way to 'offline init' a full backup in a 'VirtualFull',
> eg a way not to trasfer 4TB of data at 10Mbit/s for the initial full
> backup?
>
>
A full backup in Bacula can be saved on any media on any location. It is
not required to make an "initial" upload. The incremental or differential
backups does not use this "initial" data saved on media, but it is using
catalog metadata only.
best regards
--
Radosław Korzeniewski
rados...@korzeniewski.net
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
