Hello, I want to backup data from system A to system B. I'm using a "file" storage pool on system B. My problem is that the available space on system B is less than twice the amount of used space on system A - i.e., I cannot store two full backups. That is Okay for me - I don't need multiple versions of each file. A single copy of each file on system A would be totally okay. Also, the data on system A changes only very slowly.
I wonder if I can achieve this with bacula. Of course I could achieve something
similar e.g. with a
simple rsync invocation, but I already use bacula for other backups and would
like to stay with a
single solution.
My best guess is that in principle this can be achieved with Incremental +
Virtual Full backups. For
each backup, first run an incremental backup, immediatly followed by a Virtual
Full. After this, one
should have one full backup with all files on system A.
What I don't know is how to get rid of the "old" data. I would need two things:
1. After the virtual full backup is run, all files not part of the new virtual
full backup should
be discarded. These are exactly the files updated by the
incremental backup in this backup run.
2. I somehow need to consolidate space in my file-volumes. If I run the above
scheme for a while,
the files belonging to the current virtual full backup will be
sparsely distributed over many
file-volumes after a while. So, the respective volumes cannot
be purged and reused and bacula
keeps creating new volumes, thereby using a lot more storage
than necessary (and available).
I've seen that there are "migration" jobs which may be able to achieve
something for (2). However,
from the docs I could not learn whether:
* a migration within a single storage pool is possible?
* I can somehow craft a "Selection Type" argument that catches all
non-discarded files and stuffs
them compactly into as few volumes as possible. I guess that after the
Virtual Full backup has
run, all the files I want to keep should "belong" to that latest virtual
full job, right? So,
selecting the files from the most recent virtual full job would do the
trick? But how do I tell
bacula to compactify this into as few volumes as possilbe?
* … this would cause the volumes to be purgeable? I guess that if I
set volume retention to 0, a
volume should be ready to purge after all files have been migrated off it?
I'm not sure how to achieve (1). I know that files also have a retention time,
but I don't want
time-based expiry - I want a file to expire as soon as it is not part of the
most recent virtual
full backup anymore. Basically, I would need some kind of "Job Retention =
keep-only-most-recent-job" setting - is there such a thing?
Also, if I solved (1), maybe (2) becomes easier: Once I deleted all outdated
files from my catalog,
just selecting "everything" in the migration job should do the trick - right?
That still leaves me
wtih the question of how to make the migration job compactify everything into
as few volumes as
possible.
Thank for any help,
Lukas
signature.asc
Description: PGP signature
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
