Hello All,

may I ask You regarding the Mystic BBS backup strategy? I was archiving the whole folder using cron. Full backup of the whole BBS folder each night. That consumed vast amount of disk space.

Now I am thinking about different strategy. In the previous one I deleted all backups older than week. I was thinking about having the backups once per
week or try to rsync it to different location. That would bring the
possibility to switch when the original is lost. But it consumes quite a lot
of bandwidth. On the other hand the most would be consumed during the first backup. And incremental syncs wouldn't be that large.

What the backup strategy using rsync is missing is missing is the opportunity to go back in time. Once the backup location is synced and original corrupted there is no way to restore.

Any ideas? Comments?

Thanks in advance

|08Shinobi <.Phenom.>

--- Mystic BBS v1.12 A42 2018/12/30 (Linux/64)
* Origin: Infoline BBS (21:1/153)

may I ask You regarding the Mystic BBS backup strategy? I was archiving the whole folder using cron. Full backup of the whole BBS folder each night. That consumed vast amount of disk space.

If you are just backing up Mystic it shouldn't take up much space at all.

Do you have your file bases in the MYSTIC tree?

I personally will have Mystic in /mystic/ and then my file bases in /mysticfiles/ or something like that, so I can just ZIP up Mystic tree for a backup. It doesn't take more than a couple of megabytes.

I have been considering making a small backup function in MUTIL to make it easier for people. But all that would probably do is ZIP up C:\mystic, c:\mystic\data, c:\mystic\text, c:\mystic\menus, c:\mystic\scripts and then allow you to specify some custom directories too.

Keep in mind those directories would not backup your file bases or message content (just the configurations).

--- Mystic BBS v1.12 A43 2019/02/17 (Linux/64)
* Origin: Sector 7 (21:1/108)

the whole folder using cron. Full backup of the whole BBS folder each night. That consumed vast amount of disk space.
Now I am thinking about different strategy. In the previous one I

I guess I'll just combine and simplify it. I'll rsync to location with more space and tar gzip it on daily basis and delete the old.

Thanks for listening

|08Shinobi <.Phenom.>

--- Mystic BBS v1.12 A42 2018/12/30 (Linux/64)
* Origin: Infoline BBS (21:1/153)

Hello All,

may I ask You regarding the Mystic BBS backup strategy? I was
archiving the whole folder using cron. Full backup of the whole BBS
folder each night. That consumed vast amount of disk space.

Now I am thinking about different strategy. In the previous one I
deleted all backups older than week. I was thinking about having the backups once per week or try to rsync it to different location. That
would bring the possibility to switch when the original is lost. But
it consumes quite a lot of bandwidth. On the other hand the most
would be consumed during the first backup. And incremental syncs
wouldn't be that large.

What the backup strategy using rsync is missing is missing is the opportunity to go back in time. Once the backup location is synced
and original corrupted there is no way to restore.

What I did was move /mystic/files to an outside partition then symlinked
files back to the mystic root folder.. now when I do backups it skips
over the file bases (tar cvjpf bbs-backup.tar.bz2 *) does not follow
symlinks so it wont archive your filebase .. much smaller backups

uBuntu/derivatives have a 'snapshot' feature that will allow you to
schedule snaps of full drives or folders .. you could setup a nightly
backup and have it either rsync to another device or simply send the
backup somewhere via sftp


--- MagickaBBS v0.12alpha (Linux/x86_64)
* Origin: Internal Dimension [idbbs.dlinkddns.com:2023] (21:1/178)

may I ask You regarding the Mystic BBS backup strategy? I was archivi the whole folder using cron. Full backup of the whole BBS folder each night. That consumed vast amount of disk space.

If you are just backing up Mystic it shouldn't take up much space at all. Do you have your file bases in the MYSTIC tree?

Yes, I do. And that's the real reason it consumes so much space. Thanks for
the advice to backup only the system files. That's something that didn't come to my mind.

Keep in mind those directories would not backup your file bases or
message content (just the configurations).

Well... after some decision I've finally chosen the strategy using the rsync
to location with more space and archiving the folder using tar -zcvf. The advantage it has it I've in this solution full stand-by copy of the system. Just tried to bring it up. And it works. So after the rsync I've fresh copy
of the live environment. It can serve as development environment too. And that's something I'm really glad to have. On the other hand the daily
archives of the rsync copy target keeps me with the opportunity to rollback
the changes when something goes wrong. I guess I'm finally happy with my
backup strategy.

Thank You very much for Your help & listening & response

|08Shinobi <.Phenom.>

--- Mystic BBS v1.12 A42 2018/12/30 (Linux/64)
* Origin: Infoline BBS (21:1/153)

What I did was move /mystic/files to an outside partition then symlinked files back to the mystic root folder.. now when I do backups it skips
over the file bases (tar cvjpf bbs-backup.tar.bz2 *) does not follow symlinks so it wont archive your filebase .. much smaller backups

That's very good. G00r00 advised the same principle. As I wrote the rsync to target from source to location with more space and then archiving the target with full backups somehow solved my struggle. As I wrote what that brought is development environment and possibility to rollback in case of failure.

uBuntu/derivatives have a 'snapshot' feature that will allow you to schedule snaps of full drives or folders .. you could setup a nightly backup and have it either rsync to another device or simply send the backup somewhere via sftp

Thanks for that. Didn't know about it. I'm kind of scared of anything more
than 3 lines of shell script. I remember very well the very first disaster I had on my harddrive. The reason for that was several bad sectors on the disk. And I could not recover just because I had the disk compression. All data became unusable. Just because I could use 12 MB more than 40MB disk allowed. From that time I'm doubtful about just anything fancy.

After all the solution is simple as this:

#!/bin/bash
rsync -razv --delete <bbs_host>:/app/bbs /app
tar -zcvf /app/arc/bbs_`date +%Y%m%d`.tgz /app/bbs
find /app/arc -type f -mtime +7 -name '*.tgz' -execdir rm -- '{}' \;

Thank You for Your response

|08Shinobi <.Phenom.>

--- Mystic BBS v1.12 A42 2018/12/30 (Linux/64)
* Origin: Infoline BBS (21:1/153)

development environment too. And that's something I'm really glad to
have. On the other hand the daily archives of the rsync copy target
keeps me with the opportunity to rollback the changes when something
goes wrong. I guess I'm finally happy with my backup strategy.

Awesome! I need to look into doing a backup on my new BBS too. Right now I don't have any backup being created, but since I only have myself as the only user its not too risky.

I do want to make a simple backup and restore function in MUTIL at some point. I haven't put a lot of thought into it though but its on my TODO list.

--- Mystic BBS v1.12 A43 2019/02/17 (Linux/64)
* Origin: Sector 7 (21:1/108)