カテゴリー: Linux

CentOS7にduplicityをインストール

CentOS7にduplicityをインストール

■epel導入

# yum install https://mirrors.kernel.org/fedora-epel/7/x86_64/e/epel-release-7-5.noarch.rpm

■python tools導入

# yum install python-devel librsync-devel librsync python-setuptools python-lockfile python-boto wget

■Duplicityのソースを取得、解凍、インストール

# wget https://code.launchpad.net/duplicity/0.6-series/0.6.26/+download/duplicity-0.6.26.tar.gz
# tar xvf duplicity-0.6.26.tar.gz
# cd duplicity-0.6.26
# python setup.py build
# python setup.py install
# duplicity --version

Duplicity 0.6 series is being deprecated:
See http://www.nongnu.org/duplicity/

duplicity 0.6.26

■FTPも使うのでncftpもインストール

# yum install ncftp

とりあえずこれでOK。

■参考
Installing Duplicity for Backups on CentOS 7

install duplicity on centos 64bit

■以前の記事
duplicityをCentOS6.3にインストールするメモ

duplicityをCentOS6.3にインストールするメモ

duplicity で1日前のデータを復元する

duplicity で1日前のデータを復元する

CentOS5系にduplicityをインストールする

CentOS5系にduplicityをインストールする

CentOS6の特定のサーバでMondo Rescueが動かなかった件

CentOS6の特定のサーバでMondo Rescueが動かなかった件

ログを見ると

mkisofs: Uh oh, I cant find the boot image ‘isolinux.bin’

と出ていた。

かなりいろいろ調べてみたけどまったくわからなかった。

ふと再度バージョンを確認すると・・・

mindiのバージョンだけmondorescue-testのものになってた。

# mindi -v
Mindi v3.0.220160107015217-r3494M
# mondoarchive -v
mondoarchive v3.2.1-r3456

最初のインストール時にmondoをmondorescue-testから入れて、
それから削除してとかやってたからmindiとバージョンがあわなく
なっちゃったんだな。

入れなおし後。

# mindi -v
Mindi v3.0.1-r3456
# mondoarchive -v
mondoarchive v3.2.1-r3456

それにしてもエラーメッセージからはまったく気づけなかった。。

さくらVPSのCentOS6をMondRescueでさくらVPSにリストアしてみた。

さくらVPSのCentOS6をMondRescueでリストアしてみた。

無料お試しのVPS2Gを借りて、デフォルトインストールされている
CentOS6をバックアップしてisoをダウンロードしてから、
同じサーバに対してisoイメージインストールでリストアを実験してみた。

一応再度インストール方法から。

今回の対象はCentOS release 6.7です。

# wget ftp://ftp.mondorescue.org//rhel/6/x86_64/mondorescue.repo
# mv mondorescue.repo /etc/yum.repos.d/
# yum -y install dvd+rw-tools
# yum install --enablerepo=mondorescue mondo
# yum install lzop
# cd /
# mkdir backup
# mondoarchive -Oi -L -N -s 4480m -d /backup -E /backup -p sakura-`hostname`-`date +%Y-%m-%d`

出来たisoファイルをダウンロードしておく。

その後、さくらVPSの管理画面にログインして「OSインストール」から「ISOイメージインストール」を選択する。
「SFTP」のアカウントを作成するボタンがあるのでクリックしてISOイメージアップロード先の情報を取得する。

SFTPで接続して「iso」フォルダに先ほどダウンロードしておいたisoイメージファイルをアップロードする。

アップロード終了後に再度「OSインストール」から「ISOイメージインストール」に進むと、
アップロードしたisoファイルが表示されているはずなので内容を確認してさらに「VirtIOを有効にする」の
チェックを外してから「設定内容を確認する」をクリック。
確認画面が出るので「インストールを実行する」をクリックしてリストアを開始する。

※「VirtIOを有効にする」にチェックが入っていた状態だと「expert」モードの時に「fdisk -l」しても
デバイスが無いも表示されなかったので、チェックを外した。

Mondo Rescueの画面になるので「expert」を入力する。

boot: expert
sh-4.1# fdisk -l

/dev/sdaとかが表示されているはず。

sh-4.1# vi /tmp/mountlist.txt

ファイル内の「vda」の箇所をすべて「sda」に変更する。

sh-4.1# mondorestore

「Automatically」を選択

リストアが始まる。

たぶんこの時に画面の下に

Formatting /dev/sda3 as ext4...OK
Formatting /dev/sda1 as ext4...OK
Formatting /dev/sda2 as swap...OK
All partitions were mounted OK.

が出れば順調に進んでいるはず。

次に

You will now be able to re-generate your initrd.
This is especially useful if you changed of hardware configuration,log: socket ignored cloned, made P2V, used multipath…
Do you need to do it ?

と出るので「Yes」を選択。

initrdの再作成の画面

次に

You’ll now be chrooted under your future / partition.
Go under /boot and rebuild your init(rd|ramfs) with
mkinitrd -f -v initrd-2.x.y.img 2.x.y
e.g.
or initramfs, dracut, … Then type exit to finish

と出るので「OK」を選択。

mkinitrdの再作成の画面

プロンプトでinitrdの再構築を行う。

sh-4.1# cd /boot/
sh-4.1# ls -lhtr vmlinuz*

一番下のバージョンのimgでinitrdを再生成。
今回はこんな感じだった。

sh-4.1# mkinitrd -f -v initramfs-2.6.32-573.12.1.el6.x86_64.img 2.6.32-573.12.1.el6.x86_64

再構築が終わったら

sh-4.1# exit

すこし待つと、

Because of bugs in GRUB’s own installer,
GRUB was not installed properly. Please install the boot loadermanually now,
using this chroot()’ed shell prompt. Type ‘exit’ when you have finished.

と出るので「OK」を選択。

GRUBのバグの再作成の画面

 

grubのインストールを試みる。

sh-4.1# grub-install /dev/sda
/dev/sda does not have any corresponding BIOS drive./boo

とエラーが出てしまったのでいろいろ捜索。

「/etc/mtab」に「vda」の記述が残っていることを発見したのでこれを修正する。

sh-4.1# vi /etc/mtab

それと「/boot/grub/device.map」に「vda」の記述が残っていることを発見したのでこれを修正する。

sh-4.1# vi /boot/grub/device.map

再度「grub-install」を実行。

sh-4.1# grub-install /dev/sda
・・・
(hd0)   /dev/sda

このように最後に表示されればOKっぽい。

プロンプトを抜ける。

sh-4.1# exit

最後に

Mondo has restored your system.
・・・

と表示されるので「OK」を選択。

プロンプトを抜ける。

sh-4.1# exit

その後何も起きないので、VPSの管理画面から
「強制再起動」を行う。

ログインプロンプトが表示されればOK。

今回は同じサーバにリストアしたので、ネットワーク関係の
再設定はいらないはず。

違うVPSにリストアする場合はUUID関係とかも調整しないと
いけないのかもしれない。。

今回同じサーバにも関わらず「Automatically」で全部できなかったのは
バックアップの時にカーネル検出を失敗していたのかもしれないと↓の
ブログを拝見して思いました。

さくらのVPSでOSイメージを作ってまるごとコピー

あと、VirtIOでも大丈夫って書いてある記事もあったのだけど
なんでできなかったのかは不明。

とりあえず、有事の際にローカルの仮想環境や元のVPSで
リストアできるところまでは検証できた。

Mondo Rescue リストアの実験:VirtualBoxにさくらVPS CentOS5をリストア

Mondo Rescue VirtualBoxにさくらVPSのCentOS5のリストアを行った時の記録

同じ環境にリストアするならあっさりできるかもしれないけど、
構成が違った場合に難易度が跳ね上がったので記録しておく。

参考サイトを大量に見ながら試行錯誤してできたので、以下の手順は
実際に行った順番とか違うかもしれない。。

リストア手順

昔のVPSでHDDが20GBの時のものなので、VirtualBoxのHDDのサイズは
とりあえず25GBで準備。

リカバリーのisoを設定して起動する。

ディスクの構成が違うので「expart」モードで実行

fstab -l でデバイスファイルの状態確認。
「/dev/sda」があるはず

# vi tmp/mountlist.txt

昔のVPSなので「/dev/hda1」とかになってる箇所を「/dev/sda1」という風に
「hda」を「sda」にすべて変更。

# mondorestore <- コマンドを実行

Automaticallyを選択して実行

「initrd」の再生成のアラートが出るので「OK」する。

「/」にchrootして「/boot」の下でmkinitrdを実行する

# cd /boot
# mkinitrd -f -v initrd-2.x.y.img 2.x.y

※このとき一番新しいものを選ぶ。最初間違って古いものを指定してしまい、起動時にkernel panicになってパニックになった。

# exit <- シェルを抜ける。

サーバを落としてisoイメージを抜く。

サーバの起動をする。

起動すればOK。ネットワーク関係の設定をし直す。

Kernel panicの場合はCentOSのインストールisoを用意してRescueモードを実行し、
grubとinitrdを再作成する。

自分はKernel panicになってしまったのでRescueモードで起動して修正作業を行った。

# chroot /mnt/sysimage

そんでdevice.mapの記述を変更。

# vi /boot/grub/device.map

保存してからgrub-installを実行

# grub-install /dev/sda

その後間違ったinitrdの再生成に。

# cd /boot
# ls -lhtr vmlinuz*

で一番下のものをメモ。
今回は

vmlinuz-2.6.18-348.6.1.el5 だった
initrdの作り直し。

# mkinitrd -f -v /boot/initrd-2.6.18-348.6.1.el5.img 2.6.18-348.6.1.el5
・・・
# exit
# exit

で再起動しちゃうのでサーバを落としてisoを取り外してからサーバを起動。

やっと動いた。
実際には動くまでに「Automatically」、「Interacively 」とかを何度も試し、
途中であきらめたりしながら4日間くらいかかって起動するようになりました・・・。
起動プロセスやディスク、レスキューモードとか普段めったに触らないところだったので
いちいち勉強しないといけなかった。でも実際まだよくわかっていない。

緊急用にmondo rescueでリカバリメディアを作成している人は急にリストアを
依頼されて困らないように練習しておく必要があるかもです。

これで一応ローカルでアップデートの実験とかできる。

【リストア参考サイト】
非常にお世話になりました。ありがとうございました。

■Mondo Rescueによるリストアを失敗しないために。

■さくらインターネットのVPS環境へMondo Rescueでリストアする方法 (Automatically編)

■さくらインターネットのVPS環境へMondo Rescueでリストアする方法 (Interactively編)

■さくらVPS環境をMondorescueでバックアップしてVmwareにリカバリする

■Mondo Rescue

■レスキューモードでGrubリカバリ

■起動時にkernel panicが発生する場合の対処法

Mondo RescueをCentOS5で試してエラーが出た。

Mondo RescueをCentOS5で試してエラーが出た。

■OSのバージョン
CentOS release 5.9 (Final)

■その時点での最新をインストール

# mondoarchive --version
mondoarchive v3.2.1-r3456
See man page for help
# mindi --version
Mindi v3.0.1-r3456
# mkisofs --version
mkisofs 2.01 (cpu-pc-linux-gnu)

■実行!

# mondoarchive -Oi -gF -s 4480m -d /backup -E /backup

■エラーが発生。logに以下のように…faildが・・・。

DBG3: [Main] libmondo-fork.c-&gt;run_external_binary_with_percentage_indicator_NEW#685: Parent res = 256
INFO: Call to mkisofs to make ISO (ISO #1) ...failed
DBG1: [Main] libmondo-archive.c-&gt;make_iso_fs#1883: WARNING - make_iso_fs returned an error
DBG2: [Main] libmondo-archive.c-&gt;write_iso_and_go_on#3223: Retrying, at user's request...

■以下の情報を発見。
[Mondo-devel] Newest mondo error calling mkisofs

Yes, this is a regression for non RHEL 7 versions 🙁 Please use the
test of 3.2.2 that will be out soon to foix that + some other issues
reported since.

Cf: ftp://ftp.mondorescue.org/test/rhel/5

RHEL7以外のものはダメらしいのでテストの3.2.2を入れて試す。

ftp://ftp.mondorescue.org/test/rhel/5/x86_64/
mondorescue-test.repo

■リポジトリを削除してmondorescue-test.repoを入れなおす。

# yum --enablerepo=mondorescue-test install mondo
[root@www15172u ~]# mondoarchive --version
mondoarchive v3.2.220151218023212-r3492

■実行!

# mondoarchive -Oi -gF -s 4480m -d /backup -E /backup

出来た。
とりあえずこれで凌ぐ。

リストアできるかな~

 

※その後CentOS6環境でも「mondoarchive」を試すが、こちらは「3.2.1」、「3.2.2」でもエラーが出てメディアの作成が完了しない・・・。
今のところどうしていいのかわからず途方に暮れています。⇒mindiのバージョンがずれてました・・・。

CentOS7にMondo Rescureをインストール

CentOS7にMondo Rescureをインストール

Mondo Rescureを使ってみようと思いローカル環境で実験をすることに。

最終目標はさくらのVPSのリカバリディスクの作成。

今回の実験環境
ホスト:Windows10
VirtualBox:5.0.12
Vagrant:1.8.1
ゲスト:CentOS7.2

ゲストのCentOS7.2のリカバリディスクを作成する。

※Vagrant環境なんだからpackageにすればいいんだけど「Mondo Rescure」の実験なので・・・。

作業はゲストでのみ行う。
まずはCentOS7.2にログインしてインストールから。

■yumリポジトリをインストールして「Mondo Rescure」をインストールする。

Download Mondo Rescue

ミラーサイトからリポジトリを取得

# wget ftp://mondo.mirror.pclark.com/pub/mondorescue/rhel/7/x86_64/mondorescue.repo

# mv mondorescue.repo /etc/yum.repos.d/

■インストール

# yum --enablerepo=mondorescue search mondo
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: www.ftp.ne.jp
 * epel: ftp.riken.jp
 * extras: www.ftp.ne.jp
 * remi-php70: mirrors.thzhost.com
 * remi-safe: mirrors.thzhost.com
 * updates: www.ftp.ne.jp
============================================================================================================ N/S matched: mondo =============================================================================================================
mondo.x86_64 : MondoRescue is a GPL Disaster Recovery and Cloning Solution
mondo-debuginfo.x86_64 : Debug information for package mondo
perl-MondoRescue.noarch : The perl-MondoRescue provides a set of functions for the MondoRescue project


# yum --enablerepo=mondorescue install mondo
・・・・
Complete!

以上でインストールは完了。

2つのコマンドが入った模様
mondoarchive
mondorestore

■バージョン確認

# mondoarchive -v
mondoarchive v3.2.1-r3456
See man page for help

■ISOイメージを作成してみる

オプションはこのページを参考にしました。

# mondoarchive -Oi -s 4480m -d /tmp
See /var/log/mondoarchive.log for details of backup run.
Checking sanity of your Linux distribution
Done.
Making catalog of files to be backed up
---evalcall---1---          Making catalog of /       
---evalcall---2--- TASK:  [**..................]  10% done;  0:09 to go
---evalcall---E---
---evalcall---1---          Making catalog of /       
---evalcall---2--- TASK:  [**********..........]  48% done;  0:02 to go
---evalcall---E---
---evalcall---1---          Making catalog of /       
---evalcall---2--- TASK:  [***********.........]  53% done;  0:02 to go
---evalcall---E---
---evalcall---1---          Making catalog of /       
---evalcall---2--- TASK:  [***************.....]  71% done;  0:01 to go

・・・・・

---evalcall---1---             Verifying...           
---evalcall---2--- TASK:  [******..............]  28% done;  0:02 to go
---evalcall---E---
---evalcall---1---             Verifying...           
---evalcall---2--- TASK:  [**********..........]  50% done;  0:06 to go
---evalcall---E---
Mindi failed to create your boot+data disks.
Fatal error... Failed to generate boot+data disks
---FATALERROR--- Failed to generate boot+data disks
If you require technical support, please contact the mailing list.
See http://www.mondorescue.org for details.
The list's members can help you, if you attach that file to your e-mail.
Log file: /var/log/mondoarchive.log
Mondo has aborted.
rm: cannot remove ‘/tmp/mondo.tmp.OD9jow/mountpoint.29356’: Device or resource busy
Execution run ended; result=254
Type 'less /var/log/mondoarchive.log' to see the output log

こけた?

Mondo RescueをつかってのCentOs7のバックアップ

上記のページを参考に設定値を変更してみた。

# pwd
/etc/mindi

# diff mindi.conf.org mindi.conf
12,13c12,13
< # EXTRA_SPACE=80152           # increase if you run out of ramdisk space
< # BOOT_SIZE=32768 # size of the boot disk --- > EXTRA_SPACE=240000            # increase if you run out of ramdisk space
> BOOT_SIZE=100000              # size of the boot disk

なんとなく出力先も変更して再度実行

# mondoarchive -Oi -s 4480m -d /backup -E /backup
・・・

---progress-form---3--- Please wait. This may take some time.
---progress-form---E---
---progress-form---4--- TASK:  [********************] 100% done;  0:00 to go
Done.
Writing any remaining data to media         
Please be patient. Do not be alarmed by on-screen inactivity.
Call to mkisofs to make ISO (ISO #1) ...OK
Done.
Done.
Backup and/or verify ran to completion. Everything appears to be fine.
/var/cache/mindi/mondorescue.iso, a boot/utility CD, is available if you want it
Data archived OK. 
Mondoarchive ran OK.
See /var/log/mondoarchive.log for details of backup run.
Execution run ended; result=0
Type 'less /var/log/mondoarchive.log' to see the output log

出来た!

# pwd
/backup
# ls -alh
total 1.2G
drwxr-xr-x   2 root root   30 Jan 28 06:40 .
dr-xr-xr-x. 19 root root 4.0K Jan 28 06:20 ..
-rw-r--r--   1 root root 1.2G Jan 28 06:40 mondorescue-1.iso

isoイメージは1.2GBになった。

そもそもこのサーバの使用容量はこちら↓

# df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root  8.3G  4.2G  4.1G  51% /
devtmpfs                 298M     0  298M   0% /dev
tmpfs                    308M     0  308M   0% /dev/shm
tmpfs                    308M  4.5M  304M   2% /run
tmpfs                    308M     0  308M   0% /sys/fs/cgroup
/dev/sda1                497M  230M  267M  47% /boot
tmpfs                     62M     0   62M   0% /run/user/1000

■isoが出来たのでリカバリの実験

これは参考サイト「Mondo rescueを用いたシステムリカバリの方法

と同様にVirtualBoxにisoイメージをセットして起動し、Automaticallyで実行した。
参考サイトの指示通りにやってたリカバリができた。
あとはネットワークの設定とかをやってみたらそっくりそのままの環境ができた。

ローカルでの実験ができたので稼働中のさくらVPSとかでも実行する予定。

■参考サイト
Mondo Rescue Home Page

Mondo rescueを用いたシステムリカバリの方法

Mondo Rescueを使ったVPSのマイグレーション

CentOS7でapacheユーザのumask値を変更する

CentOS7でapacheユーザのumask値を変更する

最初一生懸命「/etc/sysconfig/httpd」に「umask 002」を書いてて
反映されないなーっと思っていたら触っていたのがCnetOS7でsystemdだって
ことにしばらくたって気づいたので自戒を込めてメモ。

systemdの仕組み

実際にsystemd環境でumaskを変更するには以下の手順で。

ここに移動して

[root@localhost system]# pwd
/etc/systemd/system

このファイルを作成する

[root@localhost system]# cat httpd.service 
.include /lib/systemd/system/httpd.service
[Service]
UMask=002

これはもともとのhttpd.serviceを読み込んで、
umaskの設定だけ追加している。

systemdのリロード

[root@localhost system]# systemctl --system daemon-reload

systemdのログを確認

[root@localhost system]# journalctl -n

※参考
systemd のログを確認する journalctl

systemd のログを確認する journalctl

apache再起動

[root@localhost system]# systemctl restart httpd.service

OpenVZで「Cannot allocate memory」が出た件。

OpenVZで「Cannot allocate memory」が出た件。

開発環境でエラーが出てると報告を受ける。

$ ls
ls: error while loading shared libraries: /lib/libpthread.so.0: cannot apply additional memory protection after relocation: Cannot allocate memory

メモリって出ているけどfreeで見た感じはメモリを使いきっているわけでは無かった。

OpenVZなのでゲスト側で以下を叩いて確認。

# cat /proc/user_beancounters

kmemsizeでfailcntが出ていた。

どうもkmemsizeのリミットが14MBでそこでひっかかっている様子。

kmemsizeとは?
OS カーネルによって割り当てられるスワップ不可のメモリサイズ(バイト)。
これには、コンテナプロセスと関連付けられたすべてのカーネル内部データ構造が含まれます(ネットワークバッファは除く)。
これらのデータ構造はサーバ RAM の最初のギガバイトに常駐するため、”low” メモリと呼ばれます。

いくつに設定していいのかわからなかったので調査。

takeのとりあえず社長日記 やっとこさOpenVZ本番運用開始。
http://blog.y2ji.co.jp/archives/51826799.html

上記ブログでメモリ1GBにつき128MBくらいということなので、
今回は3GBのメモリを割り当てているので384MBを割りあててみることに。

元が14MBだったので大幅増量。大丈夫か・・・?

CPIでは32MBとという記事も見つけた。
まつぼ x Web kmemsize
http://matsu.teraren.com/blog/2010/04/22/kmemsize/

まぁしかし開発環境なので大幅に増やしてみる。

ホスト側で。

# vzctl set 175 --kmemsize 384M --save

ゲト側で確認。

# cat /proc/user_beancounters
       uid  resource           held    maxheld    barrier      limit    failcnt
      175:  kmemsize       15109212   15679488  402653184  402653184        313

limitが384MBに上がっている。

エラーも出なくなったのでしばらく様子見。。

ローカルにインストールしているJIRAが落ちた際の対応

ローカルにインストールしているJIRAが落ちた際の対応

JIRAをローカルインストールして使ったいたらいきなりJIRAが落ちた。

ログファイルを探してみてみると↓こんなエラーが・・・。

ログファイルの場所:/opt/atlassian/jira/logs/catalina.2015-11-19.log

11 19, 2015 3:16:57 午後 org.apache.catalina.startup.ContextConfig processAnnotationsFile
重大: Unable to process file [/opt/atlassian/jira/atlassian-jira/WEB-INF/classes/com/atlassian/jira/scheme/DefaultSchemeFactory.class] for annotations
java.io.FileNotFoundException: /opt/atlassian/jira/atlassian-jira/WEB-INF/classes/com/atlassian/jira/scheme/DefaultSchemeFactory.class (システム中のファイルを開きすぎです)
        at java.io.FileInputStream.open0(Native Method)
        at java.io.FileInputStream.open(FileInputStream.java:195)
        at java.io.FileInputStream.<init>(FileInputStream.java:138)
        at org.apache.catalina.startup.ContextConfig.processAnnotationsFile(ContextConfig.java:2032)
        at org.apache.catalina.startup.ContextConfig.processAnnotationsFile(ContextConfig.java:2026)
        at org.apache.catalina.startup.ContextConfig.processAnnotationsFile(ContextConfig.java:2026)
        at org.apache.catalina.startup.ContextConfig.processAnnotationsFile(ContextConfig.java:2026)
        at org.apache.catalina.startup.ContextConfig.processAnnotationsFile(ContextConfig.java:2026)
        at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1291)
        at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:876)
        at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:374)
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
        at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5378)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

「Too many open files」のエラーだと思うのでそれ関連で調べてみる。

Linux サーバでの「Too many open files」対策について
http://d.hatena.ne.jp/akishin999/20130213/1360711554

上記のサイトにたどり着いた。

今回のサーバはOpenVZで運用している「CentOS6.5」でulimitは↓の状態でした。

# ulimit -n
1024

ブログにあるとおり「/etc/sysconfig/init」の最後に追記する方法を実行。

ulimit -n 65536

で、OSをリブート。

# ulimit -n
65536

変わった!

ローカル環境なのでとりあえずこれでOK。JIRAも快調に動いてます。

duplicity で1日前のデータを復元する

duplicity で1日前のデータを復元する

久しぶりにやって忘れていたのでメモ

■duplicityで1日前のものを復元する場合
十分に空きのあるサーバで以下をroot権限で実行(元がrootでバックアップとってるので)

# duplicity -t 1D ftp://user:password@サーバ/backup/target ./

「-t」は時間指定
「-t 1D」 ⇒ 1日前の指定(相対指定)

以前のエントリに「年月日の指定方法」として書いてた・・・。

duplicityをCentOS6.3にインストールするメモ
http://www.mogumagu.com/wp/wordpress/?p=1162

再掲載

■年月日の指定方法
○年月日と時間の指定(日本時間の2008年9月4日 18:57:11)
2008-09-04T18:57:11+09:00

○年月日の指定(2008年9月4日)
2008-09-04
2008/09/04
09/04/2008
09-04-2008

○相対的な指定
3D5h45m(3日前と5時間45分前)
5Y4M15s(5年4ヶ月と15秒前)

○現在
now